From the original SynthMaker forum (2004–2014), with its members’ names and dates.
Tzarls ·
This topic is related to [old link]. There we talk about the fact that one can easily tell if a VST(i) is made with SM by just opening the dll in wordpad. Then you can see find not only a line that reads "mod.vst OSSM", but also code as plain text.
The request is: there should be no way to tell if the VST(i) was made using SM, and everything related to the schematic (code, ASM, comments, etc) shouldn`t be readable in the dll.
TomC ·
Tzarls wrote: This topic is related to [old link]. There we talk about the fact that one can easily tell if a VST(i) is made with SM by just opening the dll in wordpad. Then you can see find not only a line that reads "mod.vst OSSM", but also code as plain text.
The request is: there should be no way to tell if the VST(i) was made using SM, and everything related to the schematic (code, ASM, comments, etc) shouldn`t be readable in the dll.
+1, especially for the second part. How useful is a lockable module if the code's readable inside the .dll.
Tom
sunsynth ·
+1... of course
Walter
theun ·
+1 !
I don't care so much if users or non-SM coders can see that I use SM. It's my own responsibility to choose between SM or C++ with VST-SDK and I don't care what the KVR incrowd says ... But I don't want users or non-SM coders to read my lines of code or asm. E.g. I spent many hours studying old electronics schematics and old (1960-ies) patents in order to translate these into SM code / schematics and I do not want the whole world to be able to read that code.
Eska ·
+1!
kirkagur ·
+1
McBarGig ·
As far as the ASM code goes, Not sure what to do about that. But could'nt that file be openned in binary mode and simply replace the SM Identifier with whatever you like? We used a technique like this years ago to hide a password in an EXE file. Basically the Passwiord was a known length, and it was a static of Type String. Simply open the file in binary mode, find the string to be replaced and replace it with the exact amount of Chars... Don't know if this will still work, as I said that wa quite a few years ago...Justa thought..
matti ·
McBarGig wrote: As far as the ASM code goes, Not sure what to do about that. But could'nt that file be openned in binary mode and simply replace the SM Identifier with whatever you like? We used a technique like this years ago to hide a password in an EXE file. Basically the Passwiord was a known length, and it was a static of Type String. Simply open the file in binary mode, find the string to be replaced and replace it with the exact amount of Chars... Don't know if this will still work, as I said that wa quite a few years ago...Justa thought..
Hex-editor hacking is always fun 🙂 Could be used to do alot of other things too, like overwriting the code parts. The results just need to be tested properly.. For example if SM actually uses the code pieces when loading a VST.
Would be cool if Dev's could add some options to what gets saved inside an .osm. Or maybe instructions or tools for removing some things and packing the .dll with upx etc.. Even the current "save support for SSE/2" options are kinda cool, but very badly documented.
Tom7777 ·
+1 vote
Like for example i read online people saying they are making SM asm codes plugins, however i can tell they didn't because they make tableSM.dat files when run. Not that i care but just that shows me they didn't use pure code (used stock modules also) and also tell me that it's SM made instantly of course.
Then theres the other stuff in the other thread, im fine with people knowing that i used SM of course but the fact they can open stuff simply and take the code to use is kind of off-putting if you want to make some cool idea using code. The FL stuff also, not needed to be there in a non FL plugin, would probably speed up stuff like load times too maybe, the help and module info is not needed and it seems there is module info etc.
jobro ·
I cinsierly hope that SM puts in some checksum of sort to actually check if a DLL is modified. But one thing is for certain: My code is my code and that is something I don't want anyone to read. So a +1000 for this one!
Acrobat ·
Tom7777 wrote: Like for example i read online people saying they are making SM asm codes plugins, however i can tell they didn't because they make tableSM.dat files when run. Not that i care but just that shows me they didn't use pure code (used stock modules also) and also tell me that it's SM made in
ah ah ah ha ah 😀
Tom7777 ·
Acrobat wrote: ah ah ah ha ah 😀
😀
McBarGig ·
Just a little something thats been bothering me...and would like to know your thoughts..
I just found out that there seems to be a negative stigma surrounding SM and Synthedit, etc. I went to KVR to see about offering freeware plugs and they force you to say that they were made with SM. This is so that they can filter out these plugs when searching.
This has been bothering me a little and I thought about it, and that is probably because people have released too much crap made with these progs, not really taking into account the final product. The problem is at the other end of the spectrum you have people like me and a lot of others, who care about what they release, and as a result it seems that we're all tarnished with the same brush. Sites like KVR are only adding to this stigma. Not every plug created with SM, SE, MSP(Pluggo) are crap. In fact, I believe a plug made with SM won their dev challenge did it not?
How can you take a plug to market with this stigma attached? In fact how can you even give one away, this really pisses me off and minimizes all the hard work that a lot of SM users do and release everyday.
So, hiding our origins has now become a very strong priority for me. Malc, and devs, any thoughts on how to do this...
Tom7777 ·
McBarGig wrote: I just found out that there seems to be a negative stigma surrounding SM and Synthedit, etc. I went to KVR to see about offering freeware plugs and they force you to say that they were made with SM. This is so that they can filter out these plugs when searching.
Of course, firstly most SM plugins have slow load times, host issues and high cpu still, not all of course but some do so people prefer pure coded plugins over ones built with a dev platform. So people want to know what they are getting, some will avoid them all together but others will try them with an open opinion.
McBarGig wrote: This has been bothering me a little and I thought about it, and that is probably because people have released too much crap made with these progs, not really taking into account the final product.
There will always be crap made with development packages that make it easy for the user to create, for graphics apps also. A lot of people will upload some crap to kvr when they first make a plugin like 'wow it made some sounds' and some even charge for their first created plugin without being good with the app or even attempting to make something original. So you get a lot of 3 osc VAs with the default synth or a forum example and a few extra fx and things stuck on the end.
At the end of the day it's down to the developer to build a good reputation for the plugins they make. Even if it's coded it could be crap so i honestly think it's all down to the plugins made in the end. If you have enough people liking it even if it was avoided to begin with by someone they might try it later due to the fact people liked it so much.
McBarGig wrote: How can you take a plug to market with this stigma attached? In fact how can you even give one away, this really pisses me off and minimizes all the hard work that a lot of SM users do and release everyday.
So, hiding our origins has now become a very strong priority for me. Malc, and devs, any thoughts on how to do this...
Well if it has the common SM issues it would still get a negative reaction and also you may not be able to fix it if it's a problem with SM or at least have to wait for a update and if people are suspicious they will ask about it. Basically lying to people on KVR etc about how it was made and saying it was coded etc is not the way to go about things and if someone found out somehow then you have the status of being a untrustworthy dev also or they question all future releases.
Not that i care but i think if it's hidden you at least might have a few more testers/buyers if theres not many problems with it in peoples hosts and it's fairly good with low cpu etc. But yeah i think it's all down to the plugins made rather than the package at the end of the day. We definately need better content protection for the plugins though imo, the harder it is to extract ideas/code the better.
nix ·
I think people will look past the platform if you have a desirable sound. I sure will. Wishing contents
Nu Audio Science ·
1 I must be thick as f**k cause after reading this thread i opened all my recent plugs in Notepad++/Wordpad/PE Explorer (Admittadly i have no idea what im doing with that one) And could not find one bit of code even though my stuff was full of it, So i have no idea what thats all about i'm afraid
2 Expecting SM to ever have a good reputation is not actually a good mind set to get yourself into to be honest it is not only looked down upon by developers who hard code but also looked down upon by developers who use SE, Places like KVR are full of these developers and it is very easy to sway KVRs popular opinion just by being a dev and pretending to give a shit about KVRs members, Take the DC in recent years, Did the best plugin ever win erm no of course not, The favourite dev of the fanboys won every year simply because he shows off in the forum to the fanboys.
After all is said and done if you seriously want to make commercial plugins and all that that entails you are going to have to learn to hardcode not just because of the stigma but because to truly advance anything you are going to want the finite control over your project 😉
NAS
nix ·
stigma shmigma Thanks Outsim, glad to be able to develop at all
Tom7777 ·
Nu Audio Science wrote: 1 I must be thick as f**k cause after reading this thread i opened all my recent plugs in Notepad++/Wordpad/PE Explorer (Admittadly i have no idea what im doing with that one) And could not find one bit of code even though my stuff was full of it, So i have no idea what thats all about i'm afraid
You have to upx unpack them. It was changed in the new beta so unless it's older than that now it will be harder to spot. Before it had code module parts but there is still bits of readable text/help from modules etc, SM, CM SM, FL SM info and probably various other stuff. Personally i don't care about people knowing it's SM and never have for a while now really but i would like as best protection of the code/contents as possible.
McBarGig ·
Yep, You guys all have good points. As far as the hard coding goes. I understand what you mean and I acually am C coder. But what I use SM for is that is provides a very convenient way to create plugins. The idea here I think is to create whatever "containers" you want, then simply add your own code for that particular object. This way you can skip all the hoop jumping and bend over backwards windows stuff, and VST stuff. Just easier on GUI dev, and with ASM its really not that bad. I have a guitar Amp that runs with better CPU Usage than most of the commercial apps out there. Running 2 delays, noisegate, upsampling 6x, 2 distortion routines, another separate clean amp, Cabinet Simulator, multiple 3 way crossovers, multiple filters. Ruinning 16-17%. Inside Reaper running 12 -14% Compared with the most popular amp on the market...35 - 39% I don't know if I can name that amp here so I won't. So, what I am saying is that no one would ever get the chance to see this work as long as it gets filtered from searches.
Anyways Guys thankyou for your thoughts I was just curious what others were thinking about this matter.
So that brings me to my next question, is there any friendly sites were one can distribute their stuff or am I just writing this for myself?
nix ·
KVR isn't too bad. Here is the reception some plugs by an EssEmer here got recently-> http://www.kvraudio.com/forum/viewtopic ... ld+passion
I also release things at Image-Line and Synapse forums.
Cheers
also http://rekkerd.org
McBarGig ·
Well Tom, you make some very good points, and I would tend to agree. Thankyou for your point of view.
Nix, I have a Guitar sim for you to try as well. Get in touch...
Thanks
NothanUmber ·
Currently domain specific languages with custom editors/graphical representations and model transformations are seen as one possible upcoming trend in the IT world for the next years in order to keep really big, critical systems maintainable and understandable by specifying and testing systems at a higher abstraction level and being able to allow specialized experts (that are not necessarily "programmers" per se) to specify and review the relevant parts of the actual system.
Synthmaker could be seen as a very sophisticated kind of graphical DSL for audio plugin development with an excellent editor. So I think programs like Synthmaker will gain more credibility in the upcoming years as it will probably be more normal to have specialized, simplified and more adequate ways to describe problems and the cases were low level code is completely written with an imperative multi purpose language by hand in the first place will become less common as it is today.
Just a thought: Perhaps it could be a valuable goal to introduce an additional abstraction layer in SynthMaker in order to be able to offer (in the best case even user expandable/definable) templates that translate an intermediate SynthMaker representation into an actual implementation in a more common programming language. So one could e.g. have a C++ template for Win32 systems per default and someone could e.g. build an Objective C template that targets Mac/Cocoa or any other platform/library/implementation technique. (That would imply that "internal" components would mostly also have to be specified on the intermediate level and mappings would have to be defined in the templates in order to transform them into something that efficiently makes use of the possibilities of the target plattform. In cases were that is not suitable there could also be separate collections of target specific components that do not have to be translatable by all templates but are only mapped by a few, so e.g. a schematic that uses the assembler component could only be exportable with templates that target a x86 based platform) Then one could also mix Synthmaker generated stuff with handwritten/otherwise generated code in situations were a SynthMaker implementation or expansion is not straight forward. A custom runtime system as it is available now could stay as one possible target so people who don't need the additional options would not have to bother with an unnecessarily complicated build system and just export their vst dlls with that SM runtime as before.
NothanUmber
McBarGig ·
Hey North, some very good points and I Agree with every one of them. The "export to C++" Idea, is fabulous Imagine being able to generate your GUI and some code in SM then add the flexibility of being able to go into the code that we don't have access to in SM, that would be fantastic. Goodbye limitations. Truth be told, I use SM because it speeds up development time in a great way. Apart from some of the windows functions, it pretty much does what I need. But would I like to create the Plug in SM then export to C++ code. Sign me up.
KM
Acrobat ·
NothanUmber wrote: That would imply that "internal" components would mostly also have to be specified on the intermediate level and mappings would have to be defined in the templates in order to transform them into something that efficiently makes use of the possibilities of the target plattform. In cases were that is not suitable there could also be separate collections of target specific components that do not have to be translatable by all templates but are only mapped by a few, so e.g. a schematic that uses the assembler component could only be exportable with templates that target a x86 based platform
I think efficiency in translations is one of the most tricky thing in absolute terms... some schematics are conceived specifically for SynthMaker. Anyway I like very much the idea, also for learning pourposes, cfr. people that want to make ports, or wanna change development platform.
I see it as a different, separate application capable of making the conversion from OSM to a C compiled .txt, that will be very cool and handy!
Tom7777 ·
Yeah that would be cool, even if it was on the code module only it would be good. That would probably be much easier/faster to add in if it happens im guessing as its a SM simplified version of it as far as i know.
Nu Audio Science ·
There are people that have already made converters to convert SM code to C++ 😉 I know of one developer in particular that uses SM as a prototyping platform using the code module and then just does that very conversion for hard coding 😉
NAS
McBarGig ·
Any chance of getting him to share that with us nas?
rl ·
That's not so difficult. The following links should give you some hints: [old link] [old link]
Nu Audio Science ·
McBarGig wrote: Any chance of getting him to share that with us nas?
Nope sorry
NAS
aliasant ·
Nu Audio Science wrote: McBarGig wrote: Any chance of getting him to share that with us nas?
Nope sorry
NAS
Is it possible with this technique to convert an entire .osm build to c++ in one go?
rl ·
No, but you can copy 'n paste the C-type or ASM code into your C++ project
aliasant ·
rl wrote: No, but you can copy 'n paste the C-type or ASM code into your C++ project
Ok. Thought so. Not quite what I would like 😉 Would be nice to instead of saving to VST or .exe save to c++
McBarGig ·
You know what. If I wasn't so busy I'd sit downand write something that will take the code copied from the Code component and have it do the automatic conversion to C. Its really not that hard especially when considering that SM only has a limited set of commands. So the conversion into C would really be a snap..
Sounds like a project..A group effort KM
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker