[gmpi] Re: 3.9 Time wrap up Try #1
- From: "gogins@xxxxxxxxxxxx" <gogins@xxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Thu, 4 Mar 2004 22:25:16 -0500
Thanks for your quick response - and sorry I didn't comment earlier.
I will summarize: I agree with you that performance time and score time are
required (at a minimum); I also think that score time is more complex than
you realize. Details follow.
I was speaking of looped sequences, since "music time" has little meaning
for wav loops - although with time-stretching in real time, it could come
to have meaning! Looping software in fact already is "in between" pure wav
playback and sequenced looping.
It's where the "clocks are out of sync" that I see a missing requirement.
There are, in my mind anyway, 4 clocks:
(Clock 1) The performance clock running since start of play.
Score time. But this is more complex than you seem to realize. If one track
is looping and others are not, there is a (Clock 2) parent score time and a
child score time (Clock 3) in the looping track. In my view GMPI should
deliver all these times, and allow their manipulation, for the use cases
that I mentioned where the plugin wants to programmatically either (a)
track or (b) control these times.
As soon as the operator pauses and restarts the score (or one of its tracks
or loops) while some music continues to play, (clock 4) metronome time is
no longer identical with performance time. And it is just at this point
that a clicking or flashing metronome becomes really useful.
It is vital to understand that in a number of musical cultures and styles,
in a single performance, different performers may have different "music
times" going. The beat may advance or retard in one musician or group of
musicians relative to another. This can be true even between the left hand
and the right hand of a single pianist. If GMPI wants to play with time, I
propose that it should account for the complexity that actually exists.
Also, to return to the question of grooving, quantizing, or composing
plugins, obviously they will read one score time in, relate it to
performance time, modify it, and try to get performance time and score time
in the host to match the modified beat or location - perhaps in several
independent streams.
Original Message:
-----------------
From: Tim Hockin thockin@xxxxxxxxxx
Date: Thu, 4 Mar 2004 18:28:55 -0800
To: gmpi@xxxxxxxxxxxxx
Subject: [gmpi] Re: 3.9 Time wrap up Try #1
On Thu, Mar 04, 2004 at 07:21:11PM -0500, Michael Gogins wrote:
> "Start" means push the "play" button on the transport control. "Stop"
means
> push the "stop" or "pause" button. Pressing "play" after "pause" will not
> rewind score time, but proceed from the point at which score time was
> stopped. As for score time, it is where the cursor is in the score, if the
> host supports notation.
ok, clear on that.
> 1, 2, and 3 are indeed quite different. 1 has only scoring, no recording.
2
> has scoring plus multitrack recording, but no overdubbing. 3 has scoring,
> multitrack recording, and overdubbing. But since almost all hosts nowadays
> do 3, perhaps 1 and 2 do not seem that different from 3.
They are different in their details, but functionally they are the same. Or
rather, they all have all the same requirements of GMPI.
> 4 and 5 involve 2 and 3 plus the ability to "punch in" in the middle of a
> take. There is a logical error on my part - this really is only possible
> with 5, i.e. if overdubbing is involved. Again, most hosts do this, so the
> difference is perhaps moot.
And again, this doesn't expose any new requirements, unless I am totally
missing it.
> 6 and 7 are use cases where "performance time" can differ from "score
time."
> The operator can create a loop. The metronome is on and ticking away. It
> might be that the length of the loop is not an integral multiple of the
> tempo. In that case, after one loop the metronome and loop's internal
"score
> time" are now different. This is a common technique in minimalist
> composition.
I'm begging you to put more details. Do you mean a loop as in a wav-file
that loops? or do you mean that you set one or more tracks to loop over a
certain region?
Assume a wav file loop:
The loop player/track has a playback head. When the head hits the
loop-end, it jumps to the loop-start. The score-time keeps-advancing.
The loop player tracks it's own playback head. Nothing else needed
Assume a loop in the sequencer:
The sequencer hits the loop-end and jumps to the loop-start. Score time
jumps backwards. If your plugin wants to treat the score-time as if it
had never changed, it can do that internally, right? But that would be
awkward, unless you guarantee symmetric jumps. If you jump from 0.75 of a
tick to 0.39 of a tick, the clocks are out of sync. That may be OK. I
just don't see where GMPI would track or deliver this info.
> It could also be the case that the operator starts a loop, or loops,
without
> quantization, at some offset from the beat or from the normal timing of
the
> loop. This is a common situation in DJing or in "laptop music." Again,
> "metronome time" and the overall host "music time" would be quite
different
> from the "music time" inside the loop or loops being played. Or the
operator
Metronome time was a bad idea. We have not one single use case for it, and
at least one significant problem with it (the sync issue above). The only
musical timeline that matters is the playback location (score time, it has
been dubbed) and MAYBE overall performance time. So far we don't have a
clear use case for anything but score time, and performance time can be
tracked by the plugin based on transport+tempo+meter.
Maybe it is useful to track Score Time (stops when transport stops, jumps
when location jumps) AND Performance Time (stops when transport stops,
never jumps) in GMPI. I can make up a use case for Performance Time:
A musical score contains things like repeats and coda/segno redirections.
The Score time will jump with these occurrences, but the performance time
will not.
[[ The host must handle the issue of jumping to a syncable
location, or the Score Time and Performance Time will not align. Further,
changes to meter may cause oddities between the two timelines. It is
unclear what a plugin would DO with this information, to warrant us
requiring it. ]]
What does everyone think? Useful? Not usefule? Take it? dump it?
> "warping time" would occur if a plugin tracked the score time, and
advanced
> or retarded the metronome relative to the score time in the middle of a
bar,
> a loop, or a phrase. Hosts do this in"groove quantize" but it would be
> interesting if plugins could do this as well. It would be very interesting
> and useful, for example, if a quantized score could be warped by a
> specialized plugin with a neural net or LISP program that can actually do
> some convincing phrasing, either for realizing a piece, or for teaching
> musicianship.
Changing the tempo? Or do you mean something else?
> "Modifying the host's timeline" is more difficult,. but again would be
most
> useful. In computer-assisted live performance, computer music people have
> been trying to get programs to pick up cues from human players. This is
> called "score tracking" or "cue tracking". Obviously, it would be most
> useful if, in overdubbing with scored or sequenced tracks, a plugin could
> track a live player's phrasing, picking up ritardando, accelerando, or
This is the tempo-tracker use case, unless I misinterpret you. We've got
that one covered :)
> rubato and causing the host to follow it. A more advanced scenario would
be
> a plugin that could recogize one motif or phrase as opposed to another,
and
> jump to the corresponding section of the score. This would enable a new
kind
> of algorithmically-assisted jamming where the player would operate the
> sequencer by playing music, as opposed to clicking on a mouse.
We discussed location-sync and location controls. We don't have an
out-and-out use case for this, much less one we deem valid, but if we
clarify the above, it could be a candidate.
So, unless I am mistaken, we've made up a use case for Performance time
(really needs to have proper use case done for it - what will a plugin DO
with that info?) and we might have a use case for plugins controlling the
score time.
Was there anything else I was supposed to get from this that I missed? I
need feedback on all th eother outstanding issues, too - for anyone who is
reading.
----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules: Please stay on topic. You are responsible for your own
words. Please respect your fellow subscribers. Please do not
redistribute anyone else's words without their permission.
Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .
----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules: Please stay on topic. You are responsible for your own
words. Please respect your fellow subscribers. Please do not
redistribute anyone else's words without their permission.
Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Other related posts:
