Am 13.04.2013 02:16, schrieb Alex Stone: > 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 [...]
Yeah, fully agree here. How about removing Input and Output tracks, and letting Wave- and Group tracks receive and send audio directly to "physical" or "jack" ports? This would greatly help newbies. And the power users can just use Group tracks instead of Input/Output tracks, no functionality gets lost. > 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. this! greetings flo > > 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
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ 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
