You'll be happy to know that unison uses a data-flow graph internally. It also allows for these patches to be nested. The problem is, while an interface like Reason is very flexible, it is also painful for more basic stuff. Noobie users, and users who want to do basic stuff, benefit greatly from a more ridgid interface.
Id like some interface that is basic, but can still allow for advanced routing. We've discussed this some and I'm confident to say "two views and one model" is not the answer. There is no way to let the user swap between views without dataloss.
So I'm leaning towards: how can we best allow both interf aces can exist side-by-side. Or, the "basic interface" is a module within the big complicated patch. Perhaps the other way around?
On Oct 26, 2010 3:12 PM, "Tobiasz Karoń" <email@example.com
> Hi there!
> There is no interface in Unison (Studio) right now, I'am thinking of how to
> organize it, what is good about LMMS's interface, what is bad and what we
> want to change.
> [image: signal path.svg]
> Here is a drawing I've made to ilustrate my idea for signal path (and GUI).
> In LMMS, instruments were confined to tracks, this has some limitations,
> espcially when there are several spaces where you can create
> tracks/instuments (main song and inside BB tracks). In LMMS it's impossible
> to move those tracks (instruments) between spaces...
> I think, how about tracks being a separate set of modules, and you just make
> signal routing to pass some notes and automated values to some instruments,
> you can as well pass some audio data to feed some vocoder created as an
> instrument (and use another instrument to feed the vocoder too).
> This is about making it not so simple as It was before, but will let us to
> do more crazy and creative things with sound in this app.
> Also the mixer should be able to do submixes and side-chain compression...
> This will require interface which will enable us to directly rout all stuff
> we need by hand. You can feed back some instrument with a signal taken from
> mixer :)
> Also the instruments could be made all modular, instead of plugins there
> could be "presets": a pre-configured structures created with modular blocks
> and with a interface designed inside the app. One could just use them and
> configure with the GUI, another one could open their internal mechanism and
> make some changes (modify instrument). Everyone can of course build his
> synthesizers from scratch, but that would be very time consuming...
> There are so many things to discuss about what it can be, what we can make
> it to be, what we want it to be...
> So I'am starting very roughly, I've got some ideas but I don't know if
> anyone is interested in them...
> Tobiasz *unfa* Karoń
> -----BEGIN GEEK CODE BLOCK-----
> Version: 3.1
> GIT/MU/P d->-- s+:-(--)> a? C++(+++)>$ ULC+(++)>$ !P? L+++>++++$ E? W++>$
> !N-? !o--? K-? !w-- O? !M-- V? PS++ PE++ !Y+ !PGP+? !t(+) 5? !X !R+ tv
> b+>+++ DI>+ D+ G e h-->- !r y--()
> ------END GEEK CODE BLOCK------