Re: [Lmuse-developer] vsti outputs question

[Tim E. R. <ter...@ro...>]

On June 1, 2011 05:58:07 am Robert Jonsson wrote:
> Hi guys,
>
> 2011/6/1 Tim E. Real <ter...@ro...>:
> > On May 31, 2011 08:35:11 pm Geoff Beasley wrote:
> >> On 06/01/2011 10:23 AM, Geoff Beasley wrote:
> >> > am i understanding correctly that if i want to output 32 audio
> >> > channels from Sample Tank 2.5 for eg, i have to create 16 stereo or 32
> >> > mono output mixer channels in musE2 first?  if so, yuk!
> >
> > Yes.
>
> Yes, I would definitely recommend creating a template.
>
> Another thing is that by default we don't bind a key combination for
> creating outputs, with a key shortcut they would be fast to create
> too.
>
> >> oh, and btw just noticed again  the stereo outputs are grouped together
> >> as 1&2,2&3,3&4,4&5  etc. &that's not what you want for stereo outputs;
> >> 1&2,3&4,5&6 etc are all that's required.
> >
> > Who says all synths will pair channels like that?
> > Why is such flexibility wrong?
> > Hell, I was even aiming to allow ANY combo of channels to be paired as
> > stereo. I looked at making ALL track types, not just synths,
> > multi-channel. But I'll spare you the agonizing details of why I had to
> > settle for this scheme instead. Just be happy for now we have
> > multi-channel at all.
>
> Indeed it's a really great addition that we can route from
> multichannel synths now, can't wait til Luis gets the new
> linuxsampler-dssi ready, rocking stuff.
>
> As for the pairing I understand that failing adding multichannel you
> wanted to allow the most flexibility though I must say I have never
> encountered any other configuration than stereo on even pairs.
Since dssi-vst can't provide us with the channel naming required to 
 do the fancy automatic tricks that Cubase can do, we are left with just
 numbered channels.
Since I could not provide complete multi-channel support for ALL
 track types, ie we don't have multi-channel Wave Tracks, I did it this way
 so that you can at least take ANY TWO consecutive channels and
 record them onto our stereo Wave Tracks, for convenience and compactness. 
Otherwise you'll have many mono wave tracks all over the place.
Think of Addictive drums. You can take two completely different unrelated 
 drum sounds on channels 4 and 5 for example, and record them to a 
 stereo track. It's as simple as that. I left the door open for flexibility. 
If I remove this, I guarantee some wiseguy will ask "why can't I do this?".

In case y'all haven't figured it out, I should explain something:
The actual track being used to house the synth remains a stereo track
 just like all the others. It uses the first two found channels as its normal
 stereo source, and applies the normal pan and volume controls etc. 
But meanwhile, ALL channels are listed in the routing output popup
 so that you can route them elsewhere and do with them as you wish.
Had I succeeded in making all tracks truly multi-channel, ALL of the
 channels would have been housed by the one synth track.
Alas, I had to leave it where the synth track (and all tracks) can be only 
 two channels max. 

Caveat: I can't quite recall must check, but I think I have some unfinished
 business in there: The first two channels available in the routing popup 
 are taken AFTER the synth track has applied pan and volume!
Could be wrong there, but hopefully it's not so bad, since the first two
 channels are already presented for use in the synth track itself.

> Hmmm, something we have never managed to support is sidechaining with
> compressors, I wonder if it would be possible to support this somehow
> now that we have all these input output routing capabilities.
> I should try and think it through :)
Can't we do that now, even before multi-channel synths were added?

When I said I looked at making ALL track types multi-channel, this included
 the ability to route ANY channel from ANY track, to ANY other channel on
 another track. This probably would have helped side-chaining, to pick and
 choose which exact channels are routed to/from wherever.
But I abandoned. The routing alone proved to be a real nightmare. 
You know how complicated the popups are now, well take that and 'square it'.

>
> > Look, how about creating your own .med template having Sample Tank with
> >  32 blank wave tracks and all necessary routes pre-made. Then you can
> > load it over and over to make new songs.
> > The audio auto-connect stuff will come, who knows, maybe sooner than
> > later.
> >
> > I spoke of this before but I'd like to elevate its importance now:
> > An /extremely/ important fix that should be attempted is:
> >
> > When multiple tracks are selected in the arranger, any operations, say
> >  for example operating the volume slider in the trackinfo strip, should
> >  apply to *all* the selected tracks.
> > This is a familiar "object and object property viewer" model.
> > Like Delphi or QtDesigner and many other apps.
>
> Interesting concept, not commonly used in audio apps but should be
> very powerful.
Yeah, I mean we're not even using multiple track selection to its fullest.

>
> > The rule with this model is that when multiple objects are selected
> >  (here 'tracks') the property viewer (here trackinfo strip for example)
> >  shows the properties of the *first* selected object (a track).
> > Then when a property is adjusted, it adjusts the that property in /all/
> >  of the selected objects.
> > Properties which are not common to /all/ of the selected objects (tracks)
> >  are greyed-out or hidden.
> >
> > You've got me thinking. Can I extend the idea to routing button popup
> > menus? Thus you could select 15 midi tracks, hit the trackinfo routing
> > buttons and presto - they're all connected. No need for the fix I have in
> > the ports list - that retroactive 'connect to all tracks' thing.
>
> Could you remind me how this is supposed to work?
> My main use case is to connect a midi input to a track but it doesn't
> get any ports connected when I do it.
Er, sorry lost me there, should work. What's the exact operation again?
Tim.

>
> Regards,
> Robert
>
> > At the moment, I think the /only/ thing which actually uses multiple
> > track selection is the 'delete selected tracks' menu item, unless
> > Florian's been using them. Other operations simply use the singular
> > 'current selected' track variable.
> > Which is just craaazy, don't you guys think?
> >
> > I must warn after thinking about this for 15 min, I definitely see
> > problems, and problems with the entire scheme.
> > But it's intriguing. A very valuable goal, I'd say.
> > It'd be a lot of work but worth every minute.
> >
> > Tim.