Posted
I'd like to present some ideas we're working on and would love to get feedback from everyone who's interested in this feature. The current state of the timeline/cues support is as follows:
* We added a parameter "Time" that includes cue markers positioned at absolute time (milliseconds, or 00:00:00.000) along with an optional label text.
* Cue markers can be moved around like other objects, or one may enter a particular time, which will move them to the corresponding position in the score
The big question we're now thinking about is how to implement the workflow. The standard case would be: Select two cues (start/stop) or a span on the "Time" vector and then select another span in musical terms (e.g. a portion of the the figure) and tell Synfire to "Fit content into cue". This would scale everything left of the start marker such that the selected content will begin exactly there, scale the content to fit between the markers, and keep the remaining music unchanged.
Another solution would be to attach a measure number (or any musical position) to each cue marker (e.g. by pointing to it) and have Synfire rescale the entire score in one go. Sounds easier to handle, if I don't miss something.
(I think I'll have to sleep over this to get a clearer idea -- any input is welcome).
Andre
(shot1.png)
Mon, 2009-04-20 - 01:16 Permalink
Im all for the plan of attaching musical context to the cues. I imagine that would be the fastest way to work. Would the cues over ride the tempo in the same way a nested container overrides its parent?
The first plan assumes there is already music written before the tempo is mapped, or else any number of empty containers, which to my mind is just clutter. It also is less nimble in terms of many adjustments.
If the musical context is attached to the markers it would be easy to quickly test a number of different beats to find where the cue should fall; even down to details of 32nd notes. This also would take care of the problem of a musical idea extending beyond the cue. Most musical ideas wont fall neatly at the beginning and end of two cues. It also keeps the containers free to move as they need to while everything stays locked in place.
That said its problem that I don't entirely have my head wrapped around. I assume time signatures will remain flexible in between cues but the tempo will have to lock up; which is fine. Perhaps a way to control the tempo as a vector percentage in between cues would allow control of the shape of acceleration and deceleration between two cues.
Mon, 2009-04-20 - 08:45 Permalink
Thanks for the input.
The entire feature is something that needs time to evolve, or otherwise we run the risk of making it more complicated than necessary. At this time, we will only add the most basic functionality, that is, add cues and associate them with musical events/measures such that Synfire can create a matching tempo map.
The general constraints we have to deal with are:
1) Time is global like Harmony and Scheme.
2) Using Time inside a container makes all its cues relative to container start. If you need global times, use Time in the root container.
3) There is only one scheme/signature per container, but that container can be moved around while the global times stay in place. Should be no problem, as Scheme does not affect absolute time or tempo.
4) The association of cues with events is not permanent. It's a one time point-and-click thing that edits the tempo map.
Andre
Sat, 2009-04-25 - 21:02 Permalink
Update: The cues work fine now and will be included with the next update. It took quite some coding behind the scenes to get that working.
It might take some extra time until the manual gets updated, so I'll post a video and demonstrate the feature. It's simple but very effective.
Andre
Sat, 2009-04-25 - 21:20 Permalink
Yep. Development finished today and we are now playing around with it for testing. I would suggest we release a "beta" version first (people concerned about stability may skip that), get some feedback and then publish the official release.
So next week seems realistic.