Direkt zum Inhalt

A number of CC/Vector related feature requests

Posted

These are a few features that I have been missing from sequencing software. Some of the ideas originate from functions found in most cg applications. This would be an in depth reworking of the way vectors are handled.

Feature 1

The ability to lock a vector, especially something like a breath controller, to the movement of a note would be very nice in Synfire.

The default mode could be a weighted "s" shape where vector data would be intelligently scaled and possibly simplified as needed with a greater weight in the space between notes; effecting, minimally, the data near the start of the note.

A non-destructive clip mode where the data in between notes would be sliced starting at the right near the attack of the second note could be assigned to a hotkey as well as the standard unlocked functionality.

Feature 2

The second feature is a bit more involved but it would be great to see a small expression editor attached to each parameter, similar to what is found in compositing applications. This would be an optional function, activated as needed.

This could allow for:

Container01.Flute01.vol = (vec1 + vec2) * (sin(2.0) * 0.5) + (random(Tempo/60) * 0.2) + Container("Blah").pitch + abs((Time.secs % 8) - 4);

The expression above is elaborate but demonstrates a number of ideas that would add a lot of rapid, non destructive control to figures. Any expression as complex as the one above would only be needed in the rarest of cases.

Where vec1 and vec2 would be multiple, unlimited figures curves for a single parameter -- an organic breath controller performance augmented with simplified dynamic adjustments. Deterministic aspects can be concatenated so they can be rendered behind the scenes before playback to remove any cpu hit.

The ability to utilize multiple cc's to accomplish different tasks is the main point.

Finally, in the form of another expression.

Takes(vec1, vec2, vec3) + vec4

or

Takes(vec1, vec2, Takes(vec3, vec4, vec5))

Where Takes would invoke a integrated ui function similar to a standard daws audio lanes -- a function for comping different takes non destructively. This kind of approach would work very well for expressive CC performances. It would also work neatly with the proposed feature.

I imaging the code-ish aspects of this implementation could be intimidating, but on the vfx side of my business, these sorts controls are in common use by artists.

I failed every year of math in high school and went to an art school. Its easy to pick up.

Feature 3

A way to render feature 2 to a single vector for fine tuning and simplicity.


Di., 05.05.2009 - 22:43 Permalink

From what I saw in the hidden "synth" sub-component of Synfire, some of what you propose, as far as the math routines are concerned, could potentially be generated/rendered/applied to vectors, what have you. Andre said that component would be fully realized in later updates.

Mi., 06.05.2009 - 21:39 Permalink

The concept of non-destructive editing works fine for audio, where one basically edits a playlist only while the raw data resides on disk. Keeping track of the changes is easy, as the playlist is a very simple data structure (a list of onsets and durations)

This is not that easy with figures, because they are deeply structured objects. Moving or transforming a segment is by far more complex than the usual cut/copy/paste operations performed on a linear audio stream. I doubt it would be doable to keep track of all sorts of figure edits while maintaining the referential integrity with another CC vector.

However, attaching CC vector snippets to segments directly (like articulations) might be a viable solution. Snippets could be cut out of a recorded performance and attached to the segments automatically. Some sort of Hyper Edit mode could be used to edit the controller data the same way it works for Velocity, Step and Length now.

Concerning the synth fragments, that's experimental stuff we use for internal testing and experiments only. It is unfinished, incoherent and not integrated with the rest. We did not include it with the product, because we realized it needs at least another year of conceptual and coding work to be useful. The ideas in our drawers would easily double the number of functions in the product. We're not yet prepared to cope with that.

Some form of improved CC support as described above is more likely to happen in a forseeable timeframe.

Mi., 06.05.2009 - 23:45 Permalink

That does make sense. I suppose the performance of a single parameter on something like a breath controller or tablet has more in common with audio than does hand drawn automation. Storing that sort of thing as streams would be interesting but its not critical.

The main one Id like to see is the cc data attached to the note and possibly some meta controls for organic cc data.

The articulation idea is interesting. WIVI has something similar to that built in to facilitate the reuse of intricate articulations but it doesn't make all that much sense having it within the sound generator.