I'm going to add a bit here.
Why do we have input busses? It seems an extra layer of setup that we could
remove and not suffer any real loss.
If tracks were capable of accepting external ports, then i would think it
easier, particularly for new users, to get up to speed fairly quickly,
adding external ports directly into tracks. For functions like mute and
solo for example, it would seem to be far easier to manage this in the
code, than have to consider those functions in input busses as well.
Count me in for removing synth tracks, and introduce those synths as
"plugins" to midi tracks, where the plugin audio output is automatically
created "behind the scenes", and those plugin audio ports appear instead as
port options
, for audio and group track inputs.
I think the above would simplify the workflow quite a bit.
Alex.
On 13 April 2013 01:34, Tim E. Real <[email protected]> wrote:
> On April 13, 2013 07:54:13 AM Geoff Beasley wrote:
> > On 04/13/2013 07:41 AM, Florian Jung wrote:
> > > Frankly, i don't like the idea
> > > of synth tracks anyway. Synthes should be the same as MIDI output
> > > devices. And not the Synth track, but rather the MIDI track(s) which
> are
> > > using that synth output shall offer these controllers.
> >
> > i was wondering what had become of you Flo - good to see you back! ;)
> >
> > yeah, this gets back to my general dislike of "everything is a track"
> > structure or MusE. I agree that Synths just don't need a track at all -
> > neither do inputs or outputs inho. but there you go.
> >
> > make better use of the mixer I say. synths should just go there,and
> > inputs and outputs - not on the timeline.
> >
> > 2c
> >
> > g
> >
>
> Yeah I have to admit, I did pose the very same question to the list
> recently "why do we have synth tracks?".
>
> (I tend to disagree about no parts on the Input and Output tracks though.
> I would enjoy parts on them so automation could be easily grouped and
> moved around.)
>
> Synths are technically both midi devices and audio tracks
> ( that is they inherit BOTH classes).
> But if we're not drawing any notes or parts on those synth tracks,
> well it kind of begs the question why bother having the tracks.
> Don't forget it was probably easier for the original dev to do it this way
> due to the midi editor graphs and lack of unified audio+midi controllers.
> Well at least we can hide synths from view for now.
> Operating their audio controllers from a midi editor involves more
> stuff related to the unified controllers, or instead presenting both
> audio and midi controllers to the user there.
> Actually now this wanders into some territory I'm covering in my local
> audio controllers branch - I mentioned being able to assign the
> midi graphs to the audio controllers. Although this is not quite the
> answer we want here as it still doesn't actually present audio graphs
> to the user.
>
> One problem is that if we allow audio controllers inside parts, then we
> need some kind of part editor to open the parts and show the automation.
> Because it's difficult to allow the user to draw points /inside/ the parts
> directly on an audio track (consider overlapping parts headaches,
> and selected parts are solid black etc).
>
> Consider group tracks: They are not midi so opening any proposed
> Group track 'parts' in the midi editor makes no sense.
> Nor are they Wave tracks, so adding audio controller graphs to the
> Wave Editor would be welcome but make no sense here either.
> Perhaps a new separate 'automation' graph editor. Make it embeddable
> so that we can re-use it inside both the Midi Editor and the Wave Editor !
>
> (Strangely enough, related to Geoff's question about Groups in another
> thread, I propose that Group tracks might be able to handle midi as well.
> Imagine. Maybe Midi Group tracks? Not saying it'd be easy but still...)
>
> Wow, there's so much material to cover here, so many angles, overlapping
> points and ideas, gives-and-takes.
> I could go on for pages but it gets too long so I'll cut it short for now.
>
> Tim.
>
>
>
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> _______________________________________________
> Lmuse-developer mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/lmuse-developer
>
------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
Lmuse-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/lmuse-developer
