From the original SynthMaker forum (2004–2014), with its members’ names and dates.
Panoply ·
Working on my drag and drop boxes, I was struck by a flash about what I was actually doing, and part of the reason my schematics always seem to spiral out of control when a synth becomes even slightly complex.
Now, conceptually, when we build a synth, we are making a real time system. Are we actually making a real time system? I don't know ... maybe a soft real time system, definitely not a hard real time system though, for hardware reasons alone, if nothing else! But the important concept here, which we definitely do adhere to, is that of processes, priorities and interrupts.
I don't think we need consider priority too much here, but interrupts and processes - maybe there is some benefit in that. How we get from our brain's desire to change something to actually producing that within the synth?
Our background process is our audio signal - the logic of connecting osc into filter into amp is always ticking away, no matter what we do. Every single sample it is checking data to evalutate what value it should be producing, or whether it should be producing it, as long as there are available CPU cycles to do so. We alter the state of this process through other interrupts - and the layer up from here is the interface. When we make changes to the interface we change the state of the audio system beneath it. In pratice - the audio system chunters away until the interface is changed - which fires an interrupt to this process, returns a new value, and lets the audio process continue.
So far, so obvious. Apart from maybe, in fact definitely, it makes sense to split our GUI to a higher level than our signal path.
Where it got interesting for me was the next stage though - what controls changes to the GUI? Well, its a bit hidden away as it currently is, and definitely obfuscated, but we are into hardware interrupts. The mouse, the midi keyboard, the computer keyboard, the screen. Following the same logic that says its a good idea to seperate out our GUI, from the audio signal, surely, its a good idea, to seperate out our hardware interrupts from our GUIs? Which isn't what is currently happening at all - they are snaked into our GUI components and audio components, with the exception of what is in the 'external' section like 'Direct Sound', or ASIO i/o - but hald of the modules in the GUI section are technically 'external' modules!
So, I started experimenting, with my first layer in the synth holding all the mouse interaction which holds all the hardware interaction, which feeds down into the GUI layer, which holds all the front panel design, which feeds into the audio signal design ... and suddenly - I number of interconnects I need is massively reduced. Everything is tidier. Everything makes more sense. I'm not forever chasing mouse signals around multiple layers. The downside is, I need to modify a lot of stock modules.
But, worth a bit of time to investigate, I reckon! Things just make more sense this way - well. Hey, maybe this isn't news to you at all, or maybe you think it is pointless, but hopefully this will flash a few lightbulbs over some heads, as it did for me 🙂
I've included a 'skeleton' .osm so if you are interested perhaps you can see what I mean a bit more ... if you want to have a play with the concept, then dive in - and hopefully this will make as much sense to you as it does to me 🙂 There are other hardware inputs I need to add to it - but I think it displays well what I'm talking about. I'm also not convinced about where to put MIDI!
Happy tinkering! 🙂
Andrew J ·
Looks like your on a similar track to some of the rest of us 🙂
GUI via wireless bus
sunsynth ·
Hmm,
nice idea...
So u use the hole Front as the Mousearea...
Give us a 2nd skeleton how a knob can work this way, please!
exonerate ·
I've had similar Ideas. I created a set up similar to yours, modified a knob to work with it. (I've actually lost what I did to a hard drive crash!) But I actually gave up on the idea because it was a lot of work with not enough benefit.
Also because I like to share my modules, other people would need to be using the same system.
Also it's very difficult because the audio and GUI is separate, it makes things less portable. Although I guess thinking about If I were to create something and share it I guess it's no problem to post the separate audio and GUI modules, after all if the other person is using the same system then it would just be a case of dropping each module into the relevant areas.
So actually an idea could be to start a project so we can all chip in and create this system. All current knobs, switches ect would have to be converted to work with it.
I'm not using SM much at the minute, but I'd definitely get back into it for such a project.
Cheers 😉
Exo
Panoply ·
Sure, no problem.
This is a very quick and dirty hack on the knob - I'm sure there might be other stuff I can rip out of there too - in fact I might have a go at rewriting bits of it.
But here, I've gone into the bitmap image knob, drilling into knob>>interaction>>knob>>control. Here I strip out the LDo control, and use the one from the first level of the schematic, with a selector and a mouse area primitive. There is various other bits of wireless activity going on ... and already I think it starts to look a lot cleaner - an effect which gets multiplied hugely at more complicated synths - especially if one starts chasing hardware interrupt signals around - you don't have to hunt the mouse click an wonder where it came from or how it got triggered anymore. Everything is done on area and position 🙂
Panoply ·
Yes, the module sharing is a big issue. Its possible of course to just develop each one in the skeleton, but potentially, that causes as many issues in a demonstration as it resolves.
sunsynth ·
Thanks Panoply,
it's simpler than i 1st thought 😉
U missed the (Snap-)Default-Moduls but it's a start...
I cannot synchronize the knobs so they must be somehow different...
no prob i need to rebuild my own from scratch anyway for this project!
maybe we use the opti-/minimized version???
So i think like exo: it's time 4 a big new Project-Thread! 🙂
@exo: would be fine 2 have u on board dude!
Walter
Panoply ·
lol, yes, sounds like a great idea 🙂
I was fiddling with the selector - easy to make wireless - not so easy to go elsewhere with it though - think I'm gonna have to rewrite it 😉
Nu Audio Science ·
Want me to move this to the project area so you can get it on ?
NAS
Panoply ·
Why not, sounds good 🙂
I'm gonna jump on these selectors, and make them work this way. May end up quite different to stock, methinks!
I'll also transfer my drag and drop stuff over ... looking forward to it already 🙂
The more ultraslinky stuff there is, the more people will want in 😉
oddson ·
Here's where I started to think about some of these issues:
Proposal - keep GUI and processing separate
(Remember To Parent and To Child primitives? They still work you know!)
My current thinking is that modules should be logically constructed to have their GUI elements collected together at the penultimate level in the hierarchy. Then if someone is using them in radically different GUI the controls and other GUI elements can be removed and replaced by a bus connector that carries the GUI info from a consolidated interface OR just replace them with the new elements in the module.
Then the interface is (analogously) the visible part of a collection of functional modules dropped into a box like Moog components OR a bunch of controls on a front-piece with wire-harness bundles to the functional modules on a circuit board like most modern electronics.
As for other aspects of rationalizing OSM construction, have you seen my tutorials? The second one is probably more useful (and more clearly written).
I'm not so sure about your point regarding hardware interrupts being 'snaked' around GUI elements. If you took this to it's logical extension you would extract out all mouse controls into one place and send them to specific GUI elements based on the coordinates of the mouse events instead of having mouse handlers in each separate control. While that's possible I'm not at all convinced it's the right way to go.
Panoply ·
Yes, I agree entirely with your analogy to a synth front panel - this is exactly where I think it makes sense to go.
I think for anything but the total initiate to the software, this provides considerably more clarity to an OSM, and should also allow for easier customisation to modules.
My interrupt thing, well, that is how it works in the OS. On a computer, it doesn't stop at the front panel of the synth, you also have the layer above that with the cursor on it 🙂, and yes, extracting all the mouse and keyboard events out of the GUI components is exactly the logical conclusion of that, and personally, exactly what I'd like to see - but that is just my personal preference - getting the GUI away from the signal path would definitely be a huge step forward!
I don't like uneeded duplication - possibly an unhealthy obsession - it seems to me that a mouse click is a mouse click is a mouse click, and it occurs before where that click occurs is noted, and before we now what we are trying to do with it, and therfore, it should be before the GUI elements in the osm.
Similarly, I'd like to strip the bitmap loader out of the Animated Knob, and just load the image once... 🙂
But its endless, there is so much to get our teeth into here 🙂
sunsynth ·
@oddson: i started SM one year later and never saw ur 'Proposal - keep GUI and processing separate'
it's great...
...the well known Tutorial is a must 4 all Users of SM!!!
btw: I never had the nerve to ask why the hell i have to purge the 'Comments' anyway
(Remember To Parent and To Child primitives? They still work you know!)
i forgot them but i'm cautious with SUPERCEDED components...
***
@Panoply:
I'd like to strip the bitmap loader out of the Animated Knob, and just load the image once
We 'Oldies' use this method already but SM manage them as 'one' internally.
McBarGig ·
Guys I did not read the entire thread, and If I'm asking something that has already been asked, sorry and feel free to call me a dumbass...
Anyways, has anyone noticed any difference in performance/memory usage using wireless as opposed to direct connections? I was just just sort of thinking that internally the difference between the two may be a global variable as opposed to a local. I don't know how this works internally in SM, it would be nice to know if Wireless components are the equivalent to global variables...
SunSynth...
About your comments on how SM manages graphics internally...I have a question...
So, if you do in fact have many knobs, I have like 230 in my latest project, and you have the image for the all these knobs loaded once in your schem then send that image to all the knobs via wireless, are you creating more of a hit resource wise than if you just left the image inside each of the 230 knobs? I have not been able to verify this either way...
Thanks,
sunsynth ·
Hmm,
hope u understand me right:
Load just once means only one loader for all exactly the same looking knobs external so you sparse it in the separate knobs...
This is also a very nice way 4 a skin changer...
McBarGig ·
Yeah I understand that SM takes all identical instances of the knob and creates one internal graphic. What I am currently doing is having one copy of a png and then sending that image out multiple times in my OSM to different knobs. Either way to the inner workings of SM I understand this does not matter as there is only one instance of that graphic anyways.
So, what I'm trying to figure out is that if I'm handling the graphical changes, then all the extra wireless connections to do that...do they cause much more of a CPU hit..?
Thanks
Nu Audio Science ·
Nope but you may find a tiny load time hit depending on how many wireless you use
Normally unnoticable though
NAS
McBarGig ·
Thanks NAS
infuzion ·
McBarGig wrote: Yeah I understand that SM takes all identical instances of the knob and creates one internal graphic. ...then all the extra wireless connections to do that...do they cause much more of a CPU hit..?
Technically, the bitmap primitive code will use only one graphic, if multiple bitmaps use the exact same graphic file. You can make different knobs (eg one [0..1], and a 2nd that is "split" ranging [-1..+1] with extra notch coding) that share the same graphic file.
Also note, when using wireless, I think there are invisible In & Out primitives & links created to connect everything up, so your primitive & link count will increase exponentially, as will your file size. That said, even though I am militant about keeping OSMs small & light a possible, I tend to use the wireless-master-bitmap for knobs like you are looking into since it is easier to reload a new graphic on that one primitive bitmap rather than to reload 10-50 knobs.
McBarGig ·
Exponential? To an order of what?
So basically, its better to not use wireless?
Damn...that means my load time will get to be quite ridiculous..?
Thanks
MCB
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker