a statement from the developers regarding module sdk, please
Archive · 200812 old posts
From the original SynthMaker forum (2004–2014), with its members’ names and dates.
MichaelBenjamin ·
it would be nice if the sm developers could make a statement regarding the module sdk.
the more i understand this program, the more it becomes evident that i heavily rely on code modules/primitives for special functions.
i cant code myself, and at the moment can understand and build some green stuff functionalities. but other basics, like wave players, oscillators, filters and envelopes are beyond me, code wise.
so there are many posts about a module sdk lately.
regarding the future of sm, i think that would be a next big step.
and i would certainly pay for good efficient primitives made by people that really understand coding.
so.. any statement?
angstrom ·
now I'm confused.
You can't code but you want an SDK ?
To my mind an SDK would be a set of classes for a C++ environment, allowing coders to create items which are not currently available.
Yet you don't code .. so what use would that be to you?
What exactly do you see coming out of an SDK for you that you can't have already. User-created custom filters, oscillators and wave players are all possible now, is there something in particular that you want ?
MichaelBenjamin ·
i want something like david haupt module pack for sm, which i can buy.
other people need the sdk for that, not me.
angstrom ·
most of the things that David Haupt created using the SE SDK are already possible using just Synthmaker. That's why I quit SE and bought SM.
Looking back at DH's 'subcontrol packs' I can see very few items in there that can't be done with SM right now. Text formatting, preset displaying, graphic envelopes, tool tips, 'text append' , 'control merge'. They were all fixes to flaws which simply don;t exist in SM.
Even if an SDK arrived, most people would use it for quite esoteric things that are specific to them. Why else - when nearly all the things that SE SDK developers create are already in SM.
I'm not arguing against an SDK, but I think you misunderstand the need for one in this app.
People can already make and sell packs if they want to, similar to those of Dave Haupt if they feel the urge, some users want a 'lockable' mode for their work - but that is not related to an SDK.
MichaelBenjamin ·
yes, maybe much is already possible, but as i saw some david haupt modules i thought it would be very nice to have a sm primitive for that.
maybe a c++ coded wave sampler module with velocity zones as a primitive.
or some filter modules. etc.
so i thought the sdk would open up many possibilities for people who know coding. maybe i am wrong, i dont know.
Nu Audio Science ·
An SDK would be nice but certainly not for Wave player with velocity zones because Outsim are releasing one of those soon anyway
And not for filters which are being done in the code module all the time and outside the code module too
Maybe what is much more suited to your question would be a lockable code module
You would find with that that there would be a lot more released
I know of some users i chat to on the IRC that they would be willing to contribute new stuff that was coded if the code module could be locked so others couldnt see there code
NAS
infuzion ·
angstrom wrote: Even if an SDK arrived, most people would use it for quite esoteric things that are specific to them. Why else - when nearly all the things that SE SDK developers create are already in SM.
Urmmm, I'd use it for 64bit audio (which is often requested), & even for 32bit SSE that SM doesn't have open yet. Also I'm sure someone could hack in LUA or their own improved MIDI/sequencer system with an SDK.
angstrom ·
yes, that's right - but the OP seems confused , that's why I was steering them away from the SDK as the answer to what I think their real problem is.
For SE : David Haupt ships a special 'lock/unlock' module with his 'sub-control packs' where you enter your serial to use his module. Chris Kerry keeps a tight rein on who buys his packs, but after a bit of piracy he stopped selling them.
The issue is not about the musical functionality that those guys added to SE, which is (mostly) already possible in SM, there were a few esoteric items, but the OP did not ask about those. The OP is asking for filters, Oscillators and other such existing and possible things. I think what they really want is "more high level modules to buy", because everything they ask for is already possible, but not for them.
You will of course be able to make some things which are not now possible, but the OP didn't ask about them. I would love the new event system to arrive, I'm sure someone could hack LUA into SM1.1 but I'm just not sure that this is what this request is about.
I think we are actually seeing the beginnings of a request for an aftermarket, so I would consider this thread more of a request for a "lockable" module than anything else.
MichaelBenjamin ·
i get what you mean, angstrom , and i agree, but im totally asking for esoteric items too.
how should i know what kind of things you can come up with codewise?
and since i will never get my head around this deep coding stuff, i would be glad to be able to use other knowledge.
meanwhile i have to dig in my mess of a module collection, try to somehow standardize them, so they can all be fed with 0-1 control for example.
in this process i loose track of who made what and whatelse and that is sad, because there seems already to be some slightly irritating attitude towards using modules which are posted here.
yes if someone bright with coding would use the sdk to build some primitives, perhaps, a sampler with velocity crossfade and sustain loop support, a nicely tuned filter and some esoteric gadgets as primitives (=locked module) i cant even dream of, i would appreciate a commercial offering.
if it can be with lockable modules, then ok. but i recognized the sdk as a step further regarding dsp possibilities.
infuzion ·
MichaelBenjamin wrote: meanwhile I have to dig in my mess of a module collection...in this process I loose track of who made what and whatelse and that is sad, because there seems already to be some slightly irritating attitude towards using modules which are posted here.
When I save someone's OSM, I put it into a folder named after their forum name. If I make a grand collection of modules into a single OSM, I atleast rename the module to include the authors' names, & sometimes include the authors in the help-text.
angstrom ·
I don't think there's a problem with using modules from here, I usually take it that if OSMs are posted they are posted to be used.
There are unspoken niceties to observe though. Such as: if someone releases a compressor OSM, don't simply spend 10 minutes changing the colours and then try and sell it as "MyCompVST". That is overstepping the mark. It's not polite behaviour
Normally in these situations I would say that if the module forms a significant part of the release then the original author ought to get a significant credit. Even if that is in an accompanying text file, it's just good manners after being given something to attribute that gift.
Of course there's differences in scale. I probably wouldn't bother with a big heartfelt thank you on a GUI for a simple pan control or something. But if I used MyCo's weird additive oscillator thing I would be tempted to call my synth "MyCo'sOscillator, by MyCo"
MichaelBenjamin ·
yes i agree, that sounds like common sense.
btw @ developers
no comment needed anymore, but if you like anyway, go ahead.
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker