[LMMS-devel] Let's discuss new ideas for interface and mechanics...

[Tobiasz Karoń]

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...

[Paul Giblock]

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,
Paul

Post by Tobiasz Karoń
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,

Post by Tobiasz Karoń
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------