Proposal - keep GUI and processing separate

Tom7777 · 15 Sept 2005

Wouldn't this all depend on a users idea for the synth though, some people like to combine the gui and the synth together for quick testing. Im a bit confused as to what you mean though as it doesn't really matter if the gui is seperate.

oddson · 15 Sept 2005

Not talking about a rule. I'm thinking of the high-level modules the devs are going to include with version 1 and something others may want to consider.

For sure it's not for everybody and maybe it's not even a good idea.

Oh... and the wireless thing in my example is a bad idea. It's just confusing to remove the inputs from the processing module. 😕

Those should be hard-wired from the ActiveGUI module.

jorge · 15 Sept 2005

oddson wrote: A newbie could plunk it into a project and connect it to others while someone else could use the processing module and do their own interface with a clear template of how to do it.

Any thoughts?

These are issues that we often wonder about, its very interesting to watch your thought process and see what conclusions you come up with.

oddson · 15 Sept 2005

jorge wrote: ...its very interesting to watch your thought process and see what conclusions you come up with.

Many people find my thought processes interesting... 😕

Or were you talking about everyone on the forum 😉

jorge · 15 Sept 2005

oddson wrote: jorge wrote: ...its very interesting to watch your thought process and see what conclusions you come up with.

Many people find my thought processes interesting... 😕

Or were you talking about everyone on the forum 😉

In this case I meant you as you're dealing with issues that are important for us at the moment for creating the high-level modules.

Tom7777 · 15 Sept 2005

Not talking about a rule. I'm thinking of the high-level modules the devs are going to include with version 1 and something others may want to consider.

Oh in that case i think its a good idea to keep the high level modules quite organized so its not to confusing if you want to edit them, but then again i doubt people creating examples will do this all the time as organizing the structure to be simple with wireless links ect can make the development time longer.

stefan · 15 Sept 2005

oddson wrote: Not talking about a rule. I'm thinking of the high-level modules the devs are going to include with version 1 and something others may want to consider.

For sure it's not for everybody and maybe it's not even a good idea.

Oh... and the wireless thing in my example is a bad idea. It's just confusing to remove the inputs from the processing module. 😕

Those should be hard-wired from the ActiveGUI module.

The stuff I've been working on so far comes in several different versions. For example:

- SVF with inputs for cutoff, resonance, mode, pitch follow etc. No GUI. - SVF with cutoff and resonance knob and mode selector, but inputs for everything as well. - SVF with GUI for everything (all knobs, selector, ADSR etc). - Seperate GUI's to be connected to GUI-less version of the SVF.

This way, the user can pick whichever he or she prefers. I avoid using wireless connections as much as possible though, since they usually end up being "hidden", and hence unintuitive. One can easily connect them outside of the modules if needed.

skOre · 15 Sept 2005

I also like to keep this on top level:

Styling my synth is a blaze with this!

oddson · 15 Sept 2005

COOL! - I've been thinking of stuff like this but haven't got the coding chops yet.

I'm just coming to the point were developing a 'coding style' is something I want to address.

stefan · 15 Sept 2005

sk0re: this is an excellent way to work when designing your own stuff. But I don't think it's good to put something even remotely similar in as standard design in the high level modules. I think they should be as "simple" as possible. For the low and mid level people, these kinds of things _rock_ though 🙂

skOre · 15 Sept 2005

Nono, absolutely 😀 just want to share some thoughts here 😉

oddson · 15 Sept 2005

stefan wrote: sk0re: this is an excellent way to work when designing your own stuff. But I don't think it's good to put something even remotely similar in as standard design in the high level modules...

No - but if aspects of the GUI aren't set 16 levels deep in the sound processing it's much easier to use something like this to customize your look.

skOre · 15 Sept 2005

But this would require some all-over standard for guis, and this is definately more an SE idea rather than an SM idea 😉

Possibly good idea then again would be fashion packs that work in a certain way (for example by the color rules that I showed above)

oddson · 15 Sept 2005

skOre wrote: But this would require some all-over standard for guis...

I'm definitely not talking about enforcing styles on anyone, if that's what you mean.

skOre · 15 Sept 2005

No, but its a thin line between standards and rules if you know what I mean. Yet I see some chance for Gui sets that use better techniques like these for other people to adept when they want to spend their time on just the audio stuff.

fritzman · 15 Sept 2005

I think it would be good to be able to design styles for GUI elements. E.g. all knobs 1-27 are style #1, all buttons are style #45, etc. Right now I would have to do a big replacement party for all my GUI elements if I wanted to change them or do I miss something here?

Maybe this is a different thread but I would like to be able to couple technical functionality with GUI functionality. E.g. a row of radio buttons. Real life situation: I want one more waveform, so I add one more node to my switch in the sound-technical schematic and at the same time (because it's coupled) another radio button pops up on my GUI (and logically in the corresponding module) which I can place where ever I want. Would be cool to have (or to be able to define) rules for where the new elements do appear (vertically, horizontally, in which distance, etc.)

So far for now, FRitz

stefan · 15 Sept 2005

fritzman wrote: I think it would be good to be able to design styles for GUI elements. E.g. all knobs 1-27 are style #1, all buttons are style #45, etc. Right now I would have to do a big replacement party for all my GUI elements if I wanted to change them or do I miss something here?

This is what you could use synced modules for, when appropriate. If all your "mini-knobs" are syncronized, you only have to change one of them.

fritzman wrote: Maybe this is a different thread but I would like to be able to couple technical functionality with GUI functionality. E.g. a row of radio buttons. Real life situation: I want one more waveform, so I add one more node to my switch in the sound-technical schematic and at the same time (because it's coupled) another radio button pops up on my GUI (and logically in the corresponding module) which I can place where ever I want. Would be cool to have (or to be able to define) rules for where the new elements do appear (vertically, horizontally, in which distance, etc.)

So far for now, FRitz

That could need some thinking... It could be doable. Maybe the selector should have an integer output stating how many inputs there are?

sambean · 15 Sept 2005

This is only slightly related but I thought it would be usefule to have an 'Instance' module.. Every Instance module would have an integer output starting at zero.. That way if you create 10 objects you can easily identify them without having to go through each one labelling it.. and instance modules would only count adjacent modules in the heirarchy so they could be grouped..

oddson · 22 Sept 2005

The instance thing is a cool idea though I don't quite get how it would be a module. 😕 ...but then I can be a little slow 😉

(I seem to recall a post of a similar/same idea but couldn't find it just now. EDIT - here's the threadI was thinking of.) ********* I can't believe you didn't point out you had already come to a similar conclusion to the point I was trying to make with this thread.

I've since looked at your strereo reverb project and it demonstates exactly the point I was originally trying to make.

It's not quite what Stefan and co. sould be doing with their high-level modules because they should have a more standard GUI but it shows how easy it would be to alter the GUI without having hunt through the processing components looking for controls.

sambean · 22 Sept 2005

I think it all comes down to a matter of taste in the end.. With the high level modules there should be the option of having the GUI attatched to the module, of having it controlled with an input and keeping the GUI's grouped together..

When I started the reverb I thought it seemed to make sense to split the main processing part and the GUI part.. I personally prefer working on both sections separately, but it does have some drawbacks..

Take for example the section that calculates the delay lengths, I have four controls that calculate lengths for the 16 delay lines and I also have a GUI element that displays each of these lengths.. If anytime I make an alteration to the calculation part, I have to re-stitch it into the GUI part, which, because of the way I've done it, is quite time consuming. It would make more sense for me to have one section for both, but this doesn't fit into my original scheme..

The best way to do it is just to keep it clear and consistent, and if there is a knob on the GUI that you can't locate in the processing part, you can always double click it to find where it is..

As for the instance module it was just an idea I had to help with identifying multiple elements, for example with the delay line calculator in the reverb, each line in the calculator has an integer input 0 -15 so it generates a unique length, it would be useful to have a module in there that generates this number automatically. I'm considering somtime in the future to increase the number of delays 2 or 4 fold and having a module like that would make such tasks easire..

I'm not really sure if it anyone else would find it useful or if I'm just being lazy labelling them myself.. Another problem may be how you could group them (say you have 2 sections each with a label 0 -15)..

But such a module would only be for convenience and organisation and the devs have many more pressing issues..

Cheers

Sam

oddson · 23 Sept 2005

sambean wrote: I think it all comes down to a matter of taste in the end.. With the high level modules there should be the option of having the GUI attached to the module, of having it controlled with an input and keeping the GUI's grouped together.

OK - first you have a perfect example file of my original point, then you go summarize the real issue in two simple sentences... 😉

First - for the end user - it's simply a matter of taste. I never meant there should be an 'approved' style of working.

Second - for the Devs or anyone trying to make modules in a way that they are easy to use in larger projects by users of varying skill levels - it should be easy to use with or without the existing GUI.

(I think part the answer may lie in having a more flexible module library management system so that users load modules appropriate to their skill level and style of working. But my thoughts on this are too naive right now to make any concrete suggestions.)

It's funny to me that I started this thread only two weeks ago as I've learned so much since then. I certainly would not post the 'proposal' the way I did knowing what I do now. (I've been looking at some of the files that I thought integrated GUI with processing too deeply in the schematics and they really don't.)

Thanks to everyone -- it's really helped me in coming to terms with how projects should be organized, even if I haven't really come to any firm conclusions yet.

infuzion · 23 Sept 2005

oddson wrote: skOre wrote: But this would require some all-over standard for guis...

I'm definitely not talking about enforcing styles on anyone, if that's what you mean.

I agree: for designing webpages, you can mix content, layout, & graphics all you want, but it makes life far easier if you split them.

Even for myself, I get lost with SM's audio stuff, but I can jump in & help w/GUI stuff. If they're seperated from the get-go, it will make my abilty to help out alot easier.