From the original SynthMaker forum (2004–2014), with its members’ names and dates.
infuzion ·
Personally, I usually find SM's default modules bloated & unoptimized. I need to have my VSTs with a small footprint, in memory, but especially with CPU usage. So, I often spend 5-30 minutes optimizing a SM module before I use it.
But, SM's modules usually are good at explaining how things happen, or atleast a rough idea. After I optimize things, the modules become less understandable, unless you understand the SM versions. & Code is easier to read the ASM for sure.
A good example would be rwillson's Orange synth. He uses alot of stock SM parts, even if tweaked abit (knobs, ADSR, filters, Ping-Pong Delay, Stereo Chorus). I'm sure I can go in & do my usual tweaks (straighten links, get rid of all that freq-Hz junk, reduce knobs, reduce stream primitives to Code, ASM the Code, etc...), & not only get the file size shurnk like 15%, but reduce CPU by about 25% (maybe 40% if I'm really lucky)!
Thing is, I've been reducing SM schematics for over a year, so I'm good at it. A newbie (or someone previewing SM) may build a larger synth, see how big the footprint is, & get frustrated. Or worried people like me would rarely use the less efficient synth they make. Conversely, a module that is a bit more self-explanatory will both help people learn, and encourage newbies with SM module system.
So in light of this, how should SM ship, how should the WIKI be used? Or perhaps there are other solutions... like people can pay me to reduce their code? 😉
infuzion ·
I voted for efficient (1st priority: CPU, size 2nd) modules included, & a WIKI entry with the legible version (perhaps with more notes, &/or a walkthrough) linked to it from SM would be really cool.
oddson ·
I think ease of use is most important. You have to understand what you're doing before you worry about CPU. And file size is a non-issue. OSMs are very compact unless they include graphics or sample data -- straightening links is a waste of time IMHO.
I personally don't use any stock modules except for controls... but when I was learning the lack of stock modules (at that time) was the biggest hurdle. And learning how they worked was tough enough without opaque programming methods being used.
infuzion ·
oddson wrote: I think ease of use is most important. You have to understand what you're doing before you worry about CPU.
I agree, but for me ease of use = small files (well, more important when I had only 256Mb of RAM on my laptop) & low CPU. There were some modules that were so large, I had to give up opening them. (Straighing links helped for these cases, since there were thousands of them).
I tend to think of modules as Object-oriented closed-boxes; I don't need to see inside if I know the expected output & it runs well. (remember, I pushed for lockable modules also) But you're right, it can help more if you are clear on what exactly is going on.
I know I'm anal, & I have a feeling a majority would side with you oddson 🙂 . That's the reason for the vote! Who knows, maybe a better idea will pop up... or I can get a side job reducing people's code!
oddson ·
I once suggested multiple levels for modules to replace the current "developer" or not system. Then I can see having modules that are less easy to read becuase you can be fairly sure the people viewing the contents understand what level they're intended for.
Since I posted my answer I've rethought the question. I use the stock controls for vertually everything I do for myself because I'm not all that interested in GUI when I'm the main audience. So I want the devs to sort out issues like multiple triggers being fired from the control guts so that my plug isn't doing the same calculations over and over without benefit. If that means the module is a little harder to grasp at its guts then so-be-it. But I don't want them to make it a mess of green wires without heirarchy just to shave a KB or two off memory use or file size.
So I guess I'm not fully in the ease-of-use-above-all-else camp.
doug4350 ·
I voted highly efficient. I would like any vsti's I use to be faster than the Enterprise when Captain Kirk is in a bad mood 🙂 . When designing, I'd like the osm to be readable. I spend time cleaning up osm's so it's clear what's being routed where. I guess that comes from looking at real electronic schematics way back when. Back then, things caught on fire if it wasn't clear when a sloppy schematic was your cookbook 🙂 . When exported, I doubt the squiggly connections are there. The computer doesn't need that. I'm sure if you saw it the way the computer did, we'd see you running down the street screaming "you did what to my creation!" 😀
As far as being rocket science inside the osm, go for it. If it's efficient and works, but nobody understands it, so what. I don't need to know every minute detail about my car to drive it. If a part of an osm is too techy, I'll ask. Obviously, others will too.
Ok, enough of my "too sense".
Aloha,
Doug
matti ·
I voted for "Legable by default, & optimized versions from SM staff or fans on the WIKI". (Whats legable btw?)
It's important for things to be in a form where everyone can understand them and learn from them. If everything is top notch optimized already, no one is going to bother diving inside to optimize or learn. It's also good to have a reason for people to stop by at the community website 😉
AndydeMaro ·
Big vote of number one from me.
All New_Modules in the DownloadArea from SynthMaker, for user the buy
the Orginal Version from SynthMaker Not Support more for Ilegal Versions
andy
exonerate ·
i'd go with having optimized versions on the wiki, because i think that we should have it so that SM is as easy to learn out of the box as possible, if all the modules are highly optimized and harder to understand i think that would put a lot of people off, the learning curve in SM is already pretty high but i think that clearly laid out module's are easier to learn from,
i mean i would prefer optimized module's in some case's where i don't care what's going on inside , i just want it to do the job. but in areas where i'm trying to learn low level stuff it really helps to have everything laid out as simply as possible, so if all the module where highly optimized this would make the learning curve in SM a lot higher. it's only good for when you just what the job done effiently and don't care about the inner working's.
alot of the stuff i've learn has been though taking modules apart and playing around with them, and looking at examples to figure out how to do certain things, it wouldn't be a good thing if this method was made harder.
so yeah i think that the most sensible approach to this would be to have an optimized components section on the wiki. 😉
infuzion ·
oddson wrote: ...So I want the devs to sort out issues like multiple triggers being fired from the control guts so that my plug isn't doing the same calculations over and over without benefit. If that means the module is a little harder to grasp at its guts then so-be-it.
That can be done with timers, trigger gates, blockers, etc.
infuzion ·
Another bump for having all SM's shipped modules (esp envelopes & effects) to be fully optimized with ASM, & also all GUI modules to be minimized. Related:
Wiki Changes
1.0.9: SM VERY LAGGY with large files
If someone else wants to optimize them all & upload them, fine by me 😉
Tom7777 ·
Yeah always +1 regarding cpu and efficiancy
To be honest i have gave up on SM now really due to stuff like this and i want to actually have a plugin i make taken seriously and not thought of another slow loading, high cpu SM plugin or whatever but i follow the forum etc in some hope that i will be suprised one day and find a fix regarding cpu issues, fix for load time which are still lower than some, less bugs and roadblocks, fix for the main app in terms of building complex projects efficiancy etc.
But i see all the posts with cpu lowering over a default module so i wonder why the defaults are not follwoing the same path also. Im sure if the coding for all maths and oscs etc were to be more highly optimized using anything 'not coded' in SM would mean cpu was much less of a problem.
infuzion ·
Tom7777 wrote: To be honest i have gave up on SM now really due to stuff like this and i want to actually have a plugin i make taken seriously and not thought of another slow loading, high cpu SM plugin
You're using Reaktor now, correct? How is that CPU/memory/load-time VS SM's stock VS SM's ASM please?
Tom7777 ·
Well i find cpu is decent but it depends what it is really, i can tell you though i have seen super complex stuff compared to most SM stuff you find at a much lower CPU, theres also no noticable slowdown when browsing through giant projects unlike Sm where it takes a min + to copy and past once you get to a point. Performance wise it's great, much better than Sm, no regular crashes like in SM or they are much less rare.
I see it more as a super complex synth and effect rack myself and use it more like that but building with it is nice, and imo it has a nicer sound than Sm without adjusting tons of stuff to change it from a plain too digital sound you sometimes hear, so basically the filters and oscs sound way better imo. Definately worth checking if anyones interested in synthesis and very powerful i believe theres gonna be a update sometime also and to be honest with reaktor i really don't need many other vsts as it covers all bases.
I kind of picked SM as my dev platform of choice after having used SE which is great but i find more high level and i like to get really complex sometimes. I wanted to make my own absynth and very complex type stuff but over time with SM i noticed that it really is not up to the task and having realeased vsts for a few years i know how important cpu and efficiancy are to a user otherwise they simply choose something else and as you say people on KVR etc will instantly avoid SM stuff so if your a semi serious developer looking to get a decent following but 'not code' everything with SM it's very hard to be taken seriously at the moment and as i have said in the past the cpu etc seems to get avoided and then 'forgotten', 'revived with new posts' and then forgotten again. I still make samples etc all the time and for me reaktor is like a sample creators dream and also a great learning tool just like SM. im glad threads like this one have been made as it's ovious im not the only one thinking theres a problem with cpu etc. Add to that the FL thing, im sure it's keeping the project going but for some reason if anything i have noticed a massive slowdown in progress as soon as it happened. The way i see it is it doesn't matter how many cool things get added if nothing changes cpu/efficiancy wise. So thats kind of my reasoning for stopping the vst thing.
So im just hoping things will get better myself and for now im avoiding the whole vst making thing even though i had great fun using SM over the years and its a great app its just not up to certain tasks imo but im still keeping an eye out for anything interesting happening with it or changes efficiancy wise.
infuzion ·
Tom7777 wrote: Add to that the FL thing, I'm sure it's keeping the project going but for some reason if anything I have noticed a massive slowdown in progress as soon as it happened. The way I see it is it doesn't matter how many cool things get added if nothing changes cpu/efficiency wise. So thats kind of my reasoning for stopping the vst thing.
Still think SM is down to just Malc; seems the slowdown was before FL even. For a 1 man team, Malc does well.
IMHO, if I wanted to get another synth-builder, I would have gone Max/DSP+Pluggofor VST exports, esp after their new version.
Tom7777 ·
IMHO, if I wanted to get another synth-builder, I would have gone Max/DSP+Pluggofor VST exports, esp after their new version.
Yes max seems like a great option however on the dev side of things i understand it needs a user to install a runtime to use any vst's made with it, so if you distribute them this is a annoying thing and users don't like stuff like that etc but maybe this has changed with recent versions now im not sure. In terms of features however it's very good and i believe a lot of people use it to control/recieve hardware data etc like monome and all other sorts of interesting devices which sounds very cool. It is quite pricey however but i may look into that app sometime. For VST output apps though theres not a huge lot of options at the moment, im sure others will come though, but i kind of like SM a lot and i like it's workflow only it's not up to the task of what i need right now really in terms of what it outputs, i mean one could no doubt make absynth like stuff only they would definately not be efficiant and a total cpu hog as well as hard to build due to slowdown in the actual app as the project grows, but im hoping that it will improve over time.
No doubt malc is the main dev at the moment as you say i sometimes notice jorge visits the forum but not much interaction happens in terms of feedback etc. Also no doubt they both have 'other' jobs too that are main focus and the FL/current updates progress thing sort of shows that to a degree unless they are planning to suprise everyone with a massive update at some point or something. But right now there does seem to be a giant slowdown in progress however but at the end of the day thats not the devs fault, and im sure all the torrent sites or whatever don't help, it's just a bit frustrating as a user as things were once very active with the project.
infuzion ·
Tom7777 wrote:
IMHO, if I wanted to get another synth-builder, I would have gone Max/DSP+Pluggofor VST exports, esp after their new version.
Yes max seems like a great option however on the dev side of things I understand it needs a user to install a runtime to use any vst's made with it, so if you distribute them this is a annoying thing
I'd prefer for SM to use an external DLL instead of wrapping it inside the EXE/VST, so multiple SM plugs running at once would/could use less HD space & memory. Also, alot of VSTs use installers to put multiple files on my HD.
But, now we're getting off topic 😉
infuzion ·
Here is a real-world example of how one can save memory/HD space/internet bandwidth (even internet connects here in the States are becoming metered):
ADSR, Code with GUI, uncompressed:
SM1.1.2: 146,906 bytes
my reduction: 47,742 bytes
Now, I did cheat a bit, & hardwired the Gate property to false (one can replace it with a hardwired true if needed in < minute), but other than that it is 100% functionally the same, if not slightly CPU faster. Some other primitive & link reductions weren't that dramatic, but often are over 50%. This will help in the lagginess of larger OSMs, & perhaps avoid a few crash-bugs maybe?
edit: I'm sure reducing the size of the file will help with issues like this:
1.0.9: SM VERY LAGGY with large files
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker