From the original SynthMaker forum (2004–2014), with its members’ names and dates.
infuzion ·
Please read the posts below before voting (lots of good comments)!
It would be really neat to lock modules, so they can be sent & used by others without having the underling code exposed/openable. There are times when I'd love to release something for use, but don't want trade secrets to go out, since I might release something similar/upgraded to try to make $ off it.
Not sure if it would be worth the problem have them unlockable, so I made this poll.
oddson ·
I'm wondering if, in the process, modules could be 'compiled' and maybe even run a little faster. Then it would be worth it. It would also prevent newbies from getting too lost in the 'code' on mid-level modules.
On the other hand. I'm not trying to make money out of this so it doesn't matter to me personally.
skOre ·
I don't know. really.
fritzman ·
I think it's good to have things lockable. Look at SE: People are happy being able to use 3rd party modules. This increases the sonic range of a platform. I think lotsa SM users would be happy if they could use some super oscis and some super filters even if they wouldn't be able to see the code. E.g. I would like it if the standard SM oscis and filters would blow everything away but they simply don't. I wouldn't care too much that I don't see their code. Making things lockable is simply the same idea but on a user level.
Best wishes, FRitz
fritzman ·
It's always nice to see what people are doing to learn some more. But I prefer to get something to be able to use it in a locked package rather than not to get it at all because somebody doesn't want to share their secrets and their hard work. I have full sympathy for this. And I think that very few people would think differently if they would have developed e.g. a super mega time stretch algo which took them 1000 hours work to do it and they could make big money with it. 😉
Best wishes, FRitz
Tom7777 ·
This is something i definately want, i have lots of stuff also that i would like to share but not let people see the low level contents of the modules. A password lock type feature is something i have been wanting for a while now.
Shifrin ·
I voted that I don't care, but at the same time I know this feature would benefit a lot of people so I guess I would like to see it really! I'm pretty sure I'll always release my stuff to be picked apart, and for free, but I reserve the right to change my mind 😉 hehe.
Shif.
dasdeck ·
this compiled module idea is really good i think. also it may encourage people to share they're high quality OSC /filter/whatever modules because they could then sell them or at least can behjold their secrets (although i dont like it, that's the sad way it goes, people sell ther knowledge 😕 instead of sharing it, but i want their knowledge so i have to pay 😕 , this world is so full of animals, selfish and primitive, only the strongest survive, blah blaa, whine, whine.....) but hey! i can play with sm a bit and i forget it 😍 what a drug abuse 😈
imagine SM as a full fledged platform wich can host vst/vsti/any (popular) plugin format and sequenz stuff + you can buy/get everything as modules (filters/env/etc) and down to the almost lowest level!
would be great.
D3CK
sambean ·
I think it's a good idea too, no point in having it unlockable though, just have an option 'paste as compiled' or something..
It may also be good if some kind of basic optimisation could be done on the module after it was compiled too. I reckon there is a significant percentage of the lines of code currently created could be removed with a fairly simple optimiser..
Sam
angstrom ·
To me this ties in with the recent " SM pricing strategy" topic to a degree, in that thread the issue was limiting access to the 'library' to attract users and limit illegal exports of the library.
I think these two issues need to be, or could be solved together, perhaps a multimode 'license' module is the answer here, an extension of the 'developer' module? modes :
• developer • Locked • no-export • Locked & No-export
Tom7777 ·
Great idea angstrom, i still think there should be a password lock module as well though. The locked modules should still be able to use the properties menu also so you can customize various things like colors and labels.
NothanUmber ·
angstrom wrote: # developer # Locked # no-export # Locked & No-export
The first two options could have some good sides (a broader pool of (potentially commercial) modules to choose from. Hopefully that wouldn't lead to a situation in which every reasonably useful module would become locked, but - well it's a decision of the individual module maker at the bottom line that has to be respected of course.) As long as SM itself doesn't run as a vst I don't see too much reasonable applications for a locked module that prevents the containing schematic from being exported though... (well, one could make some "proves of concept" or demo versions of commercial modules but that could also be achieved e.g. by a locked module that periodically fades out if it's used outside of the SM application - would only require a module that provides a flag that indicates whether it runs inside SM or as a vst.).
Greetings, NothanUmber
The Sound Scientist ·
Good Day Everyone, I think lockable modules should be the least of the priorities of the developers... There are soo many other things that are more important.. Soooo many!!!! I don't think the dev's should even worry about locking modules at least till after version 1... Lets push for system stability before a new "locking" feature, c'mon guys lets be smart about this.. Much Love, 😍 Peace and Science 🙂 😀 😉
Shifrin ·
The Sound Scientist wrote: I think lockable modules should be the least of the priorities of the developers...
I have to say I tend to agree! While I understand the desire for such a thing, particularly if it means people not sharing their modules because they wish to keep the underlying schematic from prying eyes, I'd much rather see bugs squashed and SM in general becoming more stable 😉
Shif.
fritzman ·
The Sound Scientist wrote: I think lockable modules should be the least of the priorities of the developers...
Well,
I do agree. But why not discussing things like this? There was this "problem" with the independantly exportable VSTs. I think that if the devs would have been aware of how important that is they wouldn't have made those moves. Same with all other things. After all this is the "Ideas and requests" forum. So I think it's good to discuss such things. I can have a thousand ideas but it's not me who will prioritise them for the devs. They do. But they wanna hear what we think about SM.
Best wishes, FRitz
jorge ·
Tom7777 wrote: Please scramble the text or something devs in exported vsts so people cannot read it and steal content from exported vsts.
Much better would be not to save the text at all. SM actually saves the compiled code to avoid having to re-compile at loading time. The only reason the text is saved with the file is in case you want to change it later on which in the case of an exported VST is not needed at all. Should be really easy to make it not save the text with the exported VST.
Tom7777 ·
Should be really easy to make it not save the text with the exported VST.
Cool thats great, thanks Jorge 😀
stefan ·
But all of you must still keep in mind that if someone manages to find the compiled code from the code component they can quite easily convert it back to code component code. You have to be a bit of a haxx0r to be able to do these things, but it can be done. With any released software mind you, not just synthmaker dll's.
Jorge: how hard would it to make it possible to "remove source code" from a code component, so that just the compiled code is left? Would be useful for the ones that want to hide their source code when releasing modules/schematics as well, which apparently some want to 🙂
jorge ·
stefan wrote: Jorge: how hard would it to make it possible to "remove source code" from a code component, so that just the compiled code is left?
That would be easy to implement as the loaded source code isnt used unless you edit it. The disadvantage is that both the SSE and SSE2 versions of the compiled code will have to be saved. At the moment only one of them is saved and the other is compiled from the source code when required.
stefan ·
jorge wrote: stefan wrote: Jorge: how hard would it to make it possible to "remove source code" from a code component, so that just the compiled code is left?
That would be easy to implement as the loaded source code isnt used unless you edit it. The disadvantage is that both the SSE and SSE2 versions of the compiled code will have to be saved. At the moment only one of them is saved and the other is compiled from the source code when required.
It's not like we're talking about any megabyte'ish figures of ram for compiled code component code, or am I wrong? I have a vague memory of nildon's entire code ending up in the <100k area.
jorge ·
stefan wrote: It's not like we're talking about any megabyte'ish figures of ram for compiled code component code, or am I wrong? I have a vague memory of nildon's entire code ending up in the <100k area.
You're right, it would be tiny amounts of memory, just a few kilobytes per code component.
stefan ·
Just out of curiousity, do you guys feel more confident in using SM for commercial purposes now that the exported dll is encrypted (and smaller)?
djaram ·
Well Stefan, I think my simple BPM viewer has the dramatic decrease of size: 2.59MB ----> 659KB.
But drecrasing the size does not have a high priority in my list. Decreasing the time to load (the VST in the HOST) is more efficient to think of SM as a commercial purpose program. The Example.osm takes the same loading time as it used to take in the previous versions, and it's about 15 seconds in my pc!! (P4 2.4 Ghz, 512MB Ram)
Regards,
malc ·
Wow 15 seconds is a long time!
It takes 3 secs in XT on my PC (Athlon xp 2800 512Mb RAM).
Most of the time taken is for the creation of the wave tables for the sawtooth and triangle oscillators. I'll see if I can look at this again.
Out of interest how long does the example synth take to load in SM itself on your PC?
doug4350 ·
I've never timed mine, but it is in the 15 sec. ballpark, much longer than 3. Hey Malc, Wanna trade PC's -- I'll even tolerate xp for a 3 sec. load time 😀 .
I'll have to give 9.5i a try tonite when I get home...
Aloha, Doug
djaram ·
Wow 15 seconds is a long time!
It takes 3 secs in XT on my PC (Athlon xp 2800 512Mb RAM).
Most of the time taken is for the creation of the wave tables for the sawtooth and triangle oscillators. I'll see if I can look at this again.
Out of interest how long does the example synth take to load in SM itself on your PC?
Hey Malc, Example Synth takes 11 seconds to load in SM itself in my pc.
stefan ·
It takes less than ONE second to load it in SM on my PC! (Athlon64 3200+, 512 Meg RAM)
There's obviously something fishy going. Would be nice to get more people to time it, maybe it's an Intel/AMD difference issue?
dasdeck ·
maybe you can set up something , a tread or stick or a dedicated site, to make dedicated tests where people can participate.
Tom7777 ·
Just out of curiousity, do you guys feel more confident in using SM for commercial purposes now that the exported dll is encrypted (and smaller)?
I must say i now feel more confident about making and releasing commercial plugins now but as djaram said there is other things that need to be sorted like loading times, another thing is when changing presets in a SM made synth the audio sort of hangs which i don't think is very professional. Things have definately improved with recent versions though which is great. 🙂
doug4350 ·
It takes less than ONE second to load it in SM on my PC! (Athlon64 3200+, 512 Meg RAM)
There's obviously something fishy going. Would be nice to get more people to time it, maybe it's an Intel/AMD difference issue?
I think I'm to the bottom of this. The ~ 15 sec load time (for me anyways) is from firing up SM. I was able to get a 3 sec load time with SM up via File->Open after closing Ex, opening another osm, closing it and re-opening Ex.
After u/g to 95i last night, the 15 sec was reduced to about 10 sec and ~ 2.5 sec on reload.
Aloha, Doug
doug4350 ·
As a f/u to load time, I think we'll have to deal with the initial load time in hindsight of what Malc revealed on the 95i release notes. That's living the life of windows ...
edit --- To add my "too sense" to the topic, ATM, I'm impartial, but I'll probably change my mind down the road when a brain fart gives me a chance to think about it 🙂 --
Aloha, Doug
Tom7777 ·
I think I'm to the bottom of this. The ~ 15 sec load time (for me anyways) is from firing up SM. I was able to get a 3 sec load time with SM up via File->Open after closing Ex, opening another osm, closing it and re-opening Ex.
The reason SM takes a while to load is because it has to load the toolbox modules, so if like me you have lots of custom modules added you will have a much longer load time compared to someone that has just installed the program. I think complexity of the modules also effect this as well so if you add stuff like complete synths to the toolbox it will add to the load time (im guessing anyway).
infuzion ·
Tom7777 wrote: I think I'm to the bottom of this. The ~ 15 sec load time (for me anyways) is from firing up SM. I was able to get a 3 sec load time with SM up via File->Open after closing Ex, opening another osm, closing it and re-opening Ex.
The reason SM takes a while to load is because it has to load the toolbox modules, so if like me you have lots of custom modules added you will have a much longer load time compared to someone that has just installed the program. I think complexity of the modules also effect this as well so if you add stuff like complete synths to the toolbox it will add to the load time (im guessing anyway).
Also, I think an index of the modules is built each SM instance startup to help make searching for modules faster (+ a few versions ago).
boy, hasn't this thread gotten off-topic 😉
TomC ·
Just got a link to this thread, it's all dusty in here. Time for a resurrection 😈
I'd like to see the feature of lockable modules as well. Better have a module without source than having no module at all.
Cheers,
Tom
Acrobat ·
TomC wrote: Just got a link to this thread, it's all dusty in here. Time for a resurrection 😈
I'd like to see the feature of lockable modules as well. Better have a module without source than having no module at all.
Cheers,
Tom
I totally agree, Tom! +1
sunsynth ·
+1 ... +_...
Neptune ·
How about a new blank module where the "Move into Module" function is disabled (out commented)? (#pgdn)
So the developer can copy his work into such a "module M-" after finishing if he wants to share his work without showing his "secrets".
For sure such a lockable module will have the effect that some people will loose a source of inspiration to improve their own work or wont see a possibility of solution for a problem they have.
But from the point of view of an developer i fully understand that some major implementations which took n mandays of development should be hideable.
Thats simply the copyright of a developer.
Acrobat ·
Neptune wrote: How about a new blank module where the "Move into Module" function is disabled (out commented)? (#pgdn)
So the developer can copy his work into such a "module M-" after finishing if he wants to share his work without showing his "secrets".
For sure such a lockable module will have the effect that some people will loose a source of inspiration to improve their own work or wont see a possibility of solution for a problem they have.
But from the point of view of an developer i fully understand that some major implementations which took n mandays of development should be hideable.
Thats simply the copyright of a developer.
A good idea. It's true that some works may not be improved w/lockable modules but on the other hand it will stimulate SMers to direct compare different module solutions and find which one is faster/better for the case.... 🙂
exonerate ·
If it means more people would be willing to share there work then I'm all for it 😀
A locked module is better than no module.
It would just be like using primitives, although it does annoy my slightly sometimes that i can't get in and modify them. 🙂 Theres a few i really want to get inside of and change.
Cheers 😉
Exo
infuzion ·
new instruments released
TomC ·
Bumpadibump
There was just this topic AGAIN, and this is a little reminder that lockable module should not be forgotten (again) in the next release
Tom7777 ·
+1 million and a million bumps until it gets added 🙂
should not be forgotten (again)
Yeah and the same for cpu and loadtime issues etc, seems stuff like this is argued against then left always, sometimes i think im being forced to learn C++ subliminally by SM 😉
infuzion ·
Well, C++ SDK >= lockable modules & the ability for lockable modules would likely only be for the £125 / €185 /
exonerate ·
I moved the off topic discussion from the sample player thread to it's own thread in the general section Here
Only problem is I seem to have nuked the sample player thread, It's gone and I cannot find it 😊
Cheers 😉
Exo
Acrobat ·
I don't know if it's a good idea or not, but I think lockable modules can be incorporated in a whole PassWord system for SM. Well actually a plugin is itself a module - so - the ability to give modules a password access can satisfy both needs: of locking single modules and protection of plugs made with SM.
What do you think of this way?
infuzion ·
exonerate wrote: Only problem is I seem to have nuked the sample player thread, It's gone and I cannot find it 😊
Good think you're not in the military & in charge of nuclear weapons! 😉
aliasant ·
LOL
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker