Posted
Currently, there is a fixed assignment between tracks and instruments. It would be nice if this assignment could be made more flexible. For this purpose, I propose the introduction of an “Instrument” parameter.
This would work by first defining a series of instruments and assigning sounds to them. At this point, these instruments would not yet be assigned to the tracks. This assignment would be established by the new “Instrument” parameter, which were available for each of the individual tracks.
"Instruments" would be a parameter that can have as many states as there are instruments available. In this way, it would then be possible to dynamically vary the instrument with which the phrases of the respective tracks are being played during the duration of the arrangement.
This would open up a range of new possibilities: Motifs could be played alternately by different instruments without having to copy the corresponding phrases themselves. Or the motifs can be played alternately at different pitches if the different instruments are set to different playing ranges. For example, you could let a motif “pass through” from the violins via the violas and cellos to the bass.
The “Instrument” parameter could also be a vector (instead of just a single numerical value), so that several instruments could be selected at the same time. This would make it easy to create a polyphonic rendering of a phrase. Or you could easily layer different sounds. In any case, there would be a whole range of possible applications.
Wed, 2025-04-16 - 13:07 Permalink
I'm afraid this is not possible. Instruments and "tracks" have a 1:1 relationship for many different reasons.
But what you suggest can also be accomplished with phrase aliases. That's a much more realistic and versatile option that I have been thinking about for a long time already.
Wed, 2025-04-16 - 14:42 Permalink
Could tracks be "ghosted"?
IOW, track B takes all it's phrase info from track A, while still being able to itself respond to (a subset of?) parameters - such as "sound in these bars", "don't sound in these bars", etc.
I know Rapid Composer offers "ghost tracks" to good effect.
All for phrase aliases (ghosts), but the paradigm of having this possibility (also) at the track level would be quite good to have, if reasonably possible. It's a different way of thinking and constructing that is valuable in itself.
Thu, 2025-05-01 - 15:23 Permalink
You basically want separate tracks for separate musical functions in the texture (e.g., separate tracks for melody, and bass), and that way likely have less tracks overall. Did I understand that correctly? I find this useful, but I would perhaps try to implement this without relying on new Synfire features, though that may then become somewhat fiddly.
Basically, you want something like multiple key switches, but not for different articulations of a single sampler instrument, but instead for completely different instruments, right?
One way this could be implemented is using an instrument plugin that is also a plugin host, e.g., Unify. With such a plugin, you then implement some instrument that plays different instruments/plugins depending on some MIDI control. For example, with Unify you can have very many tracks per Unify instance with remote-controlled behaviour (e.g., track specific MIDI filtering or controlling mixing levels).
Here is what I might do if I would want to implement something like this.
- In the Synfire project, I might specify different key switches outside the pitch range of the respective Synfire tracks (e.g., outside the melody etc.) set as absolute notes/pitches in Synfire.
- In the Unify instance, I would define some custom MIDI filtering plugin with plugdata, that would let through all MIDI events after receiving a matching key switch, but blocking all MIDI events when receiving a MIDI note in the key switch range, but not the correct keys switch for the respective Unify track/instrument.
- In order to simplify defining such a plugdata custom MIDI plugin, I would define most of its actual programming logic within plugdata in the Lua scripting language, and then let some AI model write most of the actual code (e.g., Claude 3.7 Sonnet is quite good at this) -- such models can also directly program Pd patches, but they are better at more widely used textual languages like Lua.
- In Unify, I would then set up all the required instruments in separate tracks, each with the custom MIDI filtering plugin set to the right key switch for that instrument.
As I said, it is a bit fiddly, but definitely possible. I reckon it would take me two days or so to get this working properly.