To Jo: Simplifying event/audio workflow within mixer strips
-
- KVRAF
- 1645 posts since 24 May, 2002
ETA: s8)8)n
(can't be more specific, sorry)
(can't be more specific, sorry)
-
- KVRian
- 1378 posts since 22 Jan, 2005 from Andorra
g:):)d!!!
-
- KVRAF
- 1645 posts since 24 May, 2002
OK, did some more thinking/research about this.
Imagine that the current mixer strips are called Racks.
I dreamt about a system where sequence parts would target Racks.
A Rack could then contain midi plugs, synth, effects in any order, processed top down.
I though that that would be a great integration of many things.
But i encountered an issue:
If you send events to a Rack, then are these events for the Rack itself or for the first plug in the Rack? I guess it must be for the Rack itself, else how to control the Rack itself? (i.e. audio volume, pan & mute)
But when the events are for the Rack, the sequence parts should target a certain plug directly, not the Rack, and that's a bummer, as it kills the nice simplicity of the idea.
To allow automation of individual plugs, each plug should be targetable anyway.
Of course, part of the nice idea survives, as a Rack can still be a host for all kind of plugs, including midi plugs.
Need still to do more technical research though.
Imagine that the current mixer strips are called Racks.
I dreamt about a system where sequence parts would target Racks.
A Rack could then contain midi plugs, synth, effects in any order, processed top down.
I though that that would be a great integration of many things.
But i encountered an issue:
If you send events to a Rack, then are these events for the Rack itself or for the first plug in the Rack? I guess it must be for the Rack itself, else how to control the Rack itself? (i.e. audio volume, pan & mute)
But when the events are for the Rack, the sequence parts should target a certain plug directly, not the Rack, and that's a bummer, as it kills the nice simplicity of the idea.
To allow automation of individual plugs, each plug should be targetable anyway.
Of course, part of the nice idea survives, as a Rack can still be a host for all kind of plugs, including midi plugs.
Need still to do more technical research though.
-
- KVRist
- Topic Starter
- 95 posts since 24 Feb, 2006 from Scotland
Could events not be sent through the chain, as we have already brainstormed, by default, with an option elsewhere to use them as automation controllers for either the rack or individual plugins? Thus there would be two separate types of sequence: "standard" and automation source. It depends whether you think that automation will be used less often.
I'm sorry if this doesn't make a lot of sense . . . I'm not the brainiest when it comes to things like this.
I'm sorry if this doesn't make a lot of sense . . . I'm not the brainiest when it comes to things like this.
-
- KVRAF
- 7140 posts since 8 Feb, 2003 from London, UK
How about two targets: the rack as the simple container and "rack-control" for automating fancy bits? Just targetting the rack gets the simple "top down" flow. Think of the "rack-control" as an entry in the rack (like those controls would be in a real-world rack).muzycian wrote:If you send events to a Rack, then are these events for the Rack itself or for the first plug in the Rack? I guess it must be for the Rack itself, else how to control the Rack itself? (i.e. audio volume, pan & mute)
-
- KVRist
- Topic Starter
- 95 posts since 24 Feb, 2006 from Scotland
Yes, that's really what I mean. Individual plugins could also be targeted for automation. Otherwise, the current "top down" flow would remain.
I believe that this would enable automation in an intuitive way, while keeping the simplicity of the suggested system intact.
Thanks, pljones, for making sense of my comment!
I believe that this would enable automation in an intuitive way, while keeping the simplicity of the suggested system intact.
Thanks, pljones, for making sense of my comment!
-
- KVRian
- 892 posts since 14 Apr, 2004 from Maryland, USA
I haven't had a chance to go play, so this might be a stupid observation, but: doesn't LUNA already do this? For example, if I've got 3 VST effects in a mixer strip and I want to automate the Q on the filter effect in the third slot, there has to be some way to direct a sequence part to that VST. Or is that a post-release 1.0 capability that actually isn't there yet? (Like I said, I haven't had tie to check hands-on.) I guess this is what Jo was saying above,
Anyway, I don't know what the terminology is / ought to be, but it seems like there need to be (at least) 3 types of targets available to route a sequence part to:
1) the rack "input" for the MIDI to flow down to the first suitable "receptacle"
2) the rack as "mixer strip" whose controls (volume, pan, mutes) can be automated
3) a specific VST in a specific rack in order to automate a particular control on that VST.
The second of those doesn't apply to an audio part, but the third one might if we're talking about a compressor side-chain input or one of a vocoder's two inputs (really depends on how the individual VST is "wired"). And any send or rerouting type plug-in for a slot in a rack should be able to target the same types of destinations, for flexibility and consistency. Given that, however, an automated feature to "check routing for feedback loops" might be a useful thing to have available to invoke for a check.
I think it's paricularly important, from a usability standpoint, that the way items in the third category appear on a menu be as obvious / intuitive / logical as possible so that the user can be very clear on where something is being sent.
Sorry if I'm just stating the obvious -- I'm an engineer and like to lay these things out in clear structured ways so as to ensure I'm not missing something.
DaveL
so maybe it's not there yet.muzycian wrote:To allow automation of individual plugs, each plug should be targetable anyway.
Anyway, I don't know what the terminology is / ought to be, but it seems like there need to be (at least) 3 types of targets available to route a sequence part to:
1) the rack "input" for the MIDI to flow down to the first suitable "receptacle"
2) the rack as "mixer strip" whose controls (volume, pan, mutes) can be automated
3) a specific VST in a specific rack in order to automate a particular control on that VST.
The second of those doesn't apply to an audio part, but the third one might if we're talking about a compressor side-chain input or one of a vocoder's two inputs (really depends on how the individual VST is "wired"). And any send or rerouting type plug-in for a slot in a rack should be able to target the same types of destinations, for flexibility and consistency. Given that, however, an automated feature to "check routing for feedback loops" might be a useful thing to have available to invoke for a check.
I think it's paricularly important, from a usability standpoint, that the way items in the third category appear on a menu be as obvious / intuitive / logical as possible so that the user can be very clear on where something is being sent.
Sorry if I'm just stating the obvious -- I'm an engineer and like to lay these things out in clear structured ways so as to ensure I'm not missing something.
DaveL
-
- KVRAF
- 7140 posts since 8 Feb, 2003 from London, UK
More random musings on this topic 
.
A Part - audio or sequence - should be able to target a rack or a particular slot in a rack. (No difference between audio and sequence.)
Targetting the rack means only one thing and it's very, very simple: it's exactly the same as targetting the first *in use* slot in the rack (even if you reorganise the rack, the connections route to the first *in use* slot). (No difference between audio and sequence.)
(Maybe then the final "sound card out" could be configured for number of channels? Later, later...)
Sends should work in one of two ways:
*) Either the send plug in sends *everything* (audio, sequence data, both?)
*) Or it's configurable (audio level, sequence data filtered)
If you go for the latter, you only need a single send plugin. The former requires possibly multiple sends and then level/filter plugins. Of course, these would be useful for in-line use, so it's more modular that way. (Audio and sequence as similar as possible.)
Pan and level is another plug in. Rather than the "pre/post fader" label, you pick where to plug in the fader (if at all).
Really, we're pushing LUNA towards the modular synth idea: audio cables and control cables can be plugged in any which way. But the rack gives you a nice set of defaults. (Now, where's that post I made earlier in the year...)
.A Part - audio or sequence - should be able to target a rack or a particular slot in a rack. (No difference between audio and sequence.)
Targetting the rack means only one thing and it's very, very simple: it's exactly the same as targetting the first *in use* slot in the rack (even if you reorganise the rack, the connections route to the first *in use* slot). (No difference between audio and sequence.)
(Maybe then the final "sound card out" could be configured for number of channels? Later, later...)
Sends should work in one of two ways:
*) Either the send plug in sends *everything* (audio, sequence data, both?)
*) Or it's configurable (audio level, sequence data filtered)
If you go for the latter, you only need a single send plugin
. The former requires possibly multiple sends and then level/filter plugins. Of course, these would be useful for in-line use, so it's more modular that way. (Audio and sequence as similar as possible.)Pan and level is another plug in. Rather than the "pre/post fader" label, you pick where to plug in the fader (if at all).
Really, we're pushing LUNA towards the modular synth idea: audio cables and control cables can be plugged in any which way. But the rack gives you a nice set of defaults. (Now, where's that post I made earlier in the year...
)-
- KVRAF
- 1645 posts since 24 May, 2002
Yeah, i'm thinking in the same directions
-
- KVRian
- 1378 posts since 22 Jan, 2005 from Andorra
Pre5 this weekend?
:D-
- KVRAF
- 7140 posts since 8 Feb, 2003 from London, UK
Random question (answer not required!!): What happens if I have a sequence of Control data that I want to send to two targets..? Do I just use the same Part but with separate (what were Players) targets? Or can one Part have more than one target?
-
- KVRAF
- 1645 posts since 24 May, 2002
I've been R&Ding more on this.
It's definitely a very interesting idea!
And the problem of differentiating between the Rack as a container and the Rack as a processor itself (the volume, pan and send controls) has been successfully solved.
But a new question popped up:
If we're going to plugin synths directly in the "Racks", then how to handle synths with multiple outs?
It's definitely a very interesting idea!
And the problem of differentiating between the Rack as a container and the Rack as a processor itself (the volume, pan and send controls) has been successfully solved.
But a new question popped up:
If we're going to plugin synths directly in the "Racks", then how to handle synths with multiple outs?
-
- KVRAF
- 1645 posts since 24 May, 2002
Maybe via the rack slot context menu for synths with multi outs: "Connect Alternative Outputs" or something.
I wonder how Phrazor handles this?
And Live 6, especially with their new Rack system?
To be continued
I wonder how Phrazor handles this?
And Live 6, especially with their new Rack system?
To be continued
