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?
Btw, at unison.sf.net, you can goto hosted-apps then ideatorrent. We are
starting to capture requirements and possible solutions.
Thanks for your input,
On Oct 26, 2010 3:12 PM, "Tobiasz Karoń" <unfa00@...> wrote:
> Hi there!
> There is no interface in Unison (Studio) right now, I'am thinking of how
> 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
> 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
> to move those tracks (instruments) between spaces...
> I think, how about tracks being a separate set of modules, and you just
> signal routing to pass some notes and automated values to some
> 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
> we need by hand. You can feed back some instrument with a signal taken
> mixer :)
> Also the instruments could be made all modular, instead of plugins there
> could be "presets": a pre-configured structures created with modular
> 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
> 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------
Get latest updates about Open Source Projects, Conferences and News.