Liberty - a new modular system is coming up

[Music Engineer]

Hi all,

it's been a while since the last time i posted about RS-MET product development news here. this was not because of lack of activity - i was just breeding over something new and big that consumed all of my time. i'm planning to come up with a modular system a la Reaktor/PD/MaxMSP/SE/SM/etc. it's going to be called "Liberty" - the reason for this choice presumably obvious.

i'm now at a point where the general under-the-hood framework seems to be (mostly) done. the next steps will involve some decisions about the user interface and that's why i come here at such an early (shall we say -"pre alpha" ) stage of development. i want your input and suggestions before i make these decisions. the screenshot below shows what i have got so far:




Uploaded with ImageShack.us


those of you who are familiar with one ore more of the abovementioned modular systems will probably correctly guess that in the main area, you can insert and connect the modules. the treeview to the left represents the patch structure as ...well...tree....in a windows-explorer alike style. you can navigate through the patch by clicking on tree-nodes as well as double-clicking on (non-atomic) modules in the patch diagram. you can also move up one level in the hierarchy by double-clicking into some empty area. that will most probably stay so.

but now for the first question: what should happen when double-clicking on an atomic (i.e. non-container) module? i'm considering two options:

1.) re-using the same area as for the diagram to show a GUI for the atomic module (think, for example, a waveform-view with facilities to set loop-points etc. when the module in question is a sample player)

2.) leaving the diagram area alone and present the GUI for the atomic module in yet another area of the user interface (probably below the tree/diagram.

option 2 would also raise the question what to show in the additional area when no atomic module is selected - perhaps a global performance parameter and or preset browser interface could be shown in this case?


maybe i should say that i'm not planning to provide facilities to actually build a GUI for the patch. instead, the low-level parameters of a patch shall be edited directly on the patch-diagram level and then i want to have higher level performance parameters (or meta-parameters) that can be routed to low-level parameters and controlled from a global performance screen.


for those of you who feel like noodling around with this early pre-alpha, here it is:


www.rs-met.com/software/betas/Liberty_pre_alpha.zip


there are still a lot of bugs, though - so if you prefer to not try it, nevermind. in any case, i'd be happy to hear what you think about the user interface options.

thanks for reading, robin

[RunBeerRun]

I can't get any sound except for the noise flute patch. Do the controls have virtual range limits, like zero to ten, or zero to fifty?

[Music Engineer]

I can't get any sound except for the noise flute patch.

hmm..well...considering that the only other patch that is currently present is the empty one, that's actually expected behavior. the empty "patch" is supposed to produce silence. or are you talking about situations where you manually connect some modules that are supposed to produce some sound, but don't? generally, the catalog of useful, sound-producing modules currently has only the noise-generator. i want to wait with the implementation of the module catalog until the general, frameworkish things are all in place. actually, the "Seed" input for the noise-generator should later become a parameter that is editable from a kind of per-module-GUI (as opposed to an audio-input). the same goes for a selector of the filter-type for the BiquadDesigner (which in its current state only computes (RBJ) bandpass coefficients)

Do the controls have virtual range limits, like zero to ten, or zero to fifty?

currently, there is only the 'Constant' module which just shows a constant signal value at its output. the value can be entered from the keyboard and there are no restrictions (other than those imposed by the C++ "double" data type (64 bit floats)). later there will be a special "Parameter" module for which the user can enter minimum and maximum value, choose a mapping function (linear, exponential, etc.) and perhaps a stepsize. those things are again supposed to be editable in the Parameter's per-module-GUI. and the current value can perhaps be adjusted by a slider that sits directly in the block diagram - but this is again something that i'm still unsure about.

btw.: as for the Meta-Parameter thing - i'm also considering an interesting alternative: a functionality that stores values of all continuous parameters in a snapshot, then having an XY-pad on some global performance GUI-page, assigning a snapshot to each of the 4 corners and interpolating between the parameter-values in the snapshots according to the position in the XY-pad. ...aka preset/snapshot morphing. but it raises the question what to do with discontinuous parameters - like oscillator-waveform, number-of-breakpoints in an MSEG, etc. the easiest solution would be to simply not let such things be part of the snapshot (i.e. they are the same for all snapshots)

i'm just thinking aloud here in the hope for comments, suggestions and inspiration. so feel free to rip everything i said apart. ...meanwhile, i'll write some modules (currently sitting over a bandlimited-impulse-train (aka "buzz", in CSound terms))

[RunBeerRun]

I was trying to make a clipper or a filter, with the constant having numerical values attached to the remaining pins, haven't got any sound, although I did try to hook an addition module connecting a constant to some other pin and it honked like a car, signaling a wrong effort.

But, no sound with any connection of modules.

[Music Engineer]

ah - i can reproduce it over here, too. as said - it is still quite buggy. i'll try to find out what's going on and update the archive as soon as i fixed the issue. thanks for the hint. meanwhile - any opinions on my UI design considerations?

[RunBeerRun]

I feel it's easy to use, noticed you can resize by dragging(I think, pretty sure that wasn't just Energyxt). Double click brings you up a level.

[Music Engineer]

well, i was more like asking what i should do next. ...how to deal with / where to place those per-module GUI editors, and stuff

[Music Engineer]

OK - archive updated. i think, i fixed it. there are two new modules: BandlimitedImpulseTrain and FirstOrderLowpass - which, in combination, can be used to make an (alias-free) sawtooth oscillator. not that it matters at this stage, though. i just wanted to have something to play with. still, my main concern currently are those GUI decisions to make...

[RunBeerRun]

Cool, it's going now. I'll be testing stuff out.

[deleted]

DELETED

[Music Engineer]

i'd vote for something like 2) - think of it as an Inspector window ( maybe dockable? )
when no module is selected i could think of an Inspector for the whole patch ( analyzer view, midi information, cpu meter and stuff like that? )

yes, i'm leaning towards this option, too. with the only difference that i'd like to keep everything in one window - the inspector would then just be a rectangular area below the stuff that is currently already there (or maybe better put it above?).

-when no module is selected, i would display the global ("Performance") page - possibly with preset-browser, snapshot-morpher, n'stuff.

-when an atomic module is selected, i'd display the GUI page for that module (think of something like the GUI for EasyQ - for a multiband-EQ module)

-when a container module is selected, i could either also show the performance page, or maybe some kind of container-page which shows all numeric parameter modules inside the container (and perhaps later an oversampling factor ....more stuff i have to do...)

-when multiple modules are selected, i could show also the performance page or the container page ...or maybe a page with "actions" what to do with the selection (containerize, delete, etc.)

[Juanjo]

Just played a bit with this one, very very promising... I like how apparently you can go fairly low level within your daw in realtime, unlike other stuff that I already use such as Synthmaker (very low level, but outside the daw) or KarmaFX Synth (inside the daw but higher level). I'm keeping a close eye on it for sure, and I'd be happy to do some serious betatesting when the time comes...

Regarding the original question of where to put the "inspector"... what about a vertical strip on the right with the same size as the left-hand tree view? Several reasons for that:

a) Kinda makes more sense:
- Left: tree view of the whole project
- Center: module view of the level currently selected on the left
- Right: list view of the relevant parameters/info of the module currently selected in the center (or global controls when nothing is selected)

b) A vertical strip (on the right) seems more adequate to show a list of an arbitrary number of parameters/controls than a horizontal strip (across the bottom)

c) Regardless of the window being resizable, a left/center/right gui might be better suited for today's 16:9 or 16:10 monitors than a left/center/bottom gui


Regarding all the uses of the "inspector" mentioned in the post above... they all sound great i.e. show always useful info relevant to what's selected (or global stuff when nothing is selected).


And finally, I know it's a longshot but... any chance that it might be able to act as a host and load VST plugins as modules someday? Just a thought...

[deleted]

DELETED

[Music Engineer]

i actually like the idea with the vertical "strip" on the right hand side, too. it would give a good sense of flow from high-level structures to the low-level. but: for some of the modules that i'm planning to provide, i will need some serious horizontal GUI space. it's not like all per-module editors will be just a bunch of sliders. some may have graphic displays - think, for example, an MSEG editor. no way to sensibly fit such a thing into a narrow vertical strip. on the other hand, most per-module editors will probably indeed be just a few sliders, buttons and comboboxes. for those, a biggish GUI area would seem wasted space. hmm...looks like there's no ideal one-size-fits-all solution. but opening an extra window to show the per-module editor (which then could have a fitting size) doesn't seem too attractive either.

however, here's what i currently have:



Uploaded with ImageShack.us

(archive has been updated as well). whenever you select a module, the top-right area will show the per-module editor. most of them are empty currently - only the VoiceKiller, WhiteNoise and BiquadDesigner have some humble number of widgets on them. but as said, other modules will come that need the space.



btw.: the VoiceKiller is an idea that i had to turn off voices when they produce silence for a certain amount of time. i don't think that i have seen something like that in other modular systems and i wonder how they handle the killing of voices. if someone can enlighten me on this issue, i'd be grateful

@Juanjo:
-i'll come back to you when it's about time for the beta.
-acting as sub-host: sorry, but i have no plans for such a feature currently. it would be very complicated to integrate that into the current architecture and also, i want it to be a self-contained system - message boxes like: "Sorry, this patch can't be loaded because plugin XYZ is missing" is something i want to avoid. on the bright side, i have every intention to make such a feature unnecessary anyway by providing a comprehensive set of modules. when the beta phase begins, i'll be open for suggestions for the module catalog.

@michi_mak:
-feeling more like PD or Max/MSP is kinda intended. somehow, i like the more academic/geeky look and feel

-one mode for editing and performing, indeed. but there will be a switch to turn the audio engine off which is recommended for editing - because IIR filters (and feedback structures in general) may blow up when only partially connected, etc.

-for the automation, i have the idea to expose a fixed number (128) of meta-parameters to the host which can internally be mapped to the lower-level parameters. these meta-parameters, would then correspond to 128 VST-automation lanes and at the same time also listen for the 128 MIDI controllers. inside Liberty, i would then have a "Meta-Learn" facility for each parameter (instead of the usual MIDI learn that i currently use). thus, i would establish a one-to-one mapping between midi-controllers and 128 automation lanes. the user could then use either of the two, whichever s/he prefers (but please avoid to send conflicting data on both channels). this is my idea to deal with the messy situation of essentialy two competing automation concepts (i.e. MIDI and VST-parameters). perhaps not exactly elegant, but i have no better idea currently

[Juanjo]

...looks like there's no ideal one-size-fits-all solution. but opening an extra window to show the per-module editor (which then could have a fitting size) doesn't seem too attractive either.

Just checked the new version... I see the need for horizontal space sometimes, and I actually like your current solution, as the module being edited in the "inspector" is also selected in the project tree view, somehow preserving the visual flow of information... I'd also vote for "no floating windows at all costs", so the current implementation seems to be the optimal under the circumstances imho.

@Juanjo:
-i'll come back to you when it's about time for the beta.

Cool, I'll be watching.

-acting as sub-host: sorry, but i have no plans for such a feature currently. it would be very complicated to integrate that into the current architecture and also, i want it to be a self-contained system - message boxes like: "Sorry, this patch can't be loaded because plugin XYZ is missing" is something i want to avoid. on the bright side, i have every intention to make such a feature unnecessary anyway by providing a comprehensive set of modules. when the beta phase begins, i'll be open for suggestions for the module catalog.

I totally understand, it was just a wild idea... here's another one: any intention of implementing some kind of midi routing/processing facilities? I mean, having midi in/out modules, plus a decent set of midi generators/processors, plus arithmetic/operative modules such as counters, random generators, etc would make this a mighty midi tool as well, capable of some wild generative stuff, complete-song-in-a-module projects, etc etc... just thinking out loud.

-for the automation, i have the idea to expose a fixed number (128) of meta-parameters to the host which can internally be mapped to the lower-level parameters. these meta-parameters, would then correspond to 128 VST-automation lanes and at the same time also listen for the 128 MIDI controllers. inside Liberty, i would then have a "Meta-Learn" facility for each parameter (instead of the usual MIDI learn that i currently use). thus, i would establish a one-to-one mapping between midi-controllers and 128 automation lanes. the user could then use either of the two, whichever s/he prefers (but please avoid to send conflicting data on both channels). this is my idea to deal with the messy situation of essentialy two competing automation concepts (i.e. MIDI and VST-parameters). perhaps not exactly elegant, but i have no better idea currently

I find that pretty simple and elegant actually: no 2 controlers with the same number (i.e. Automation63 and CC63) which could easily lead to user error, and more than enough controlers for each project (as I assume that the "meta-parameter" mapping would be per-project as opposed to global, right?).

I'm liking the Liberty concept more and more...


PD: Totally off-topic but I just remembered, sorry... what happened to the 303 emulation you were developing, Acidevil I think? I loved the sound and super-simple interface/sequencer in an early beta that you posted here a while ago...