what about an 'attenuate' option, where the 'solo'd' track is left
unaffected but everything else is quietened by say 15dB or so ?
complicated i'm sure, but would be nice ;)
just a thought.
g
On 12/28/2010 01:27 AM, alex stone wrote:
> Tim, since our discussion some time ago about the limitations of the
> solo function in muse, i've been having a think. (Couple of drops of
> oil, stoke up the boiler, and the old steamer between my ears has its
> moments.)
>
>
> Our current solo function relies on a global state. So when we solo a
> midi track, it kills everything else. This is, as we discussed, a less
> than ideal function.
>
> My suggestion.
>
> If we are using midi to build up a tune, with an associated input,
> something like LS, then it makes little sense to require that midi
> solo function to be applicable for audio inputs, when we want to solo
> a midi track. We're only going to hear the selected midi track anyway,
> so no other audio is going to sound in this case.
>
> With several midi tracks, the premise is the same, solo "some" midi
> tracks, and the inputs and outputs can still remain outside the midi
> solo state, as only the selected midi tracks will send data, and only
> the associated inputs will sound.
>
> If we have some audio tracks recorded, and want to hear one or more of
> them, then the situation is different, if we have midi tracks recorded
> as well, as the midi tracks not soloed will still send data and push
> midi data, via the inputs. In this case, soloing any audio tracks also
> silences all midi tracks, except those that are soloed as well.
>
>
>
> I propose the following as an initial point of dicussion:
>
>
> Solo should work in track type blocks, that is, soloing a midi track
> silences all other midi tracks and audio tracks (and this is true if
> more than one midi track is soloed as well, only the soloed midi
> tracks send data), soloing an audio track silences all other audio and
> midi tracks, and soloing an audio track AND a midi track, silences all
> other midi and audio tracks.
>
> BUT, and this is the important bit, all inputs, busses, and outputs
> should remain in an unsoloed, audible state, unless specifically
> desired by the user.
>
> The only time inputs, busses and outputs should respond to solo or
> mute, is if the user specifically carries out actions on those track
> types. By default, they should remain outside of normal solo and mute
> functions for midi and audio tracks, so they are unaffected if solo
> and mute is used for midi and audio. If a user solos a buss, then all
> other busses are muted, but midi and audio tracks remain "audible",
> and inputs and outputs are still unaffected, and remain audible. The
> action of soloing a buss silences other busses, but that's all it
> does. (because we only want to hear whatever we've routed through that
> buss, but in order to do this, midi tracks will need to send their
> data, and recorded audio will still need to sound, if either are
> routed directly or indirectly through the selected/soloed buss)
>
>
> The idea use case is, the user presses solo for a track, be it midi or
> audio, and that's all he or she has to do.
>
>
> Comments, and scenarios/use cases i may have missed are welcome.
>
>
> Regards,
>
> Alex.
>
> ------------------------------------------------------------------------------
> Learn how Oracle Real Application Clusters (RAC) One Node allows customers
> to consolidate database storage, standardize their database environment, and,
> should the need arise, upgrade to a full multi-node Oracle RAC database
> without downtime or disruption
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Lmuse-developer mailing list
> Lmuse-developer@...
> https://lists.sourceforge.net/lists/listinfo/lmuse-developer
|