Need some help with the basics

CoreStyler · 10 May 2012

Hi. You feel disappointing visual programming? why you does not use the programming language you use at university?. Using synthmaker there a some basic thing to know: 1) there is a module hierachy 2) The components should be connected 3) you can use the internal components (primitve) for some effects (like delay's, eq, filter) 4) you can code custom algorithms with the native SM code and via Assembly If you know a lot of DSP techniques, just create an audio input/output and use the "code" component. You can write directly the code.

For example. streamin in; streamin f; streamout out; // this add input and output streams float a,b,c,x,y; //This create floating values you can set as fixed or from a streamin input. float a = 25; // this make float a =25 float b = f; //this make float b connected to stream f [not needed] a custom code can be: out = in * f; // this is a VCA.

There are many instructions, operations you can do with SM code. Look the User Manual.

By connecting streams you can test your DSP, and adding the module VSTi module you can test it with a basic synth. This as basic.

Is quite simple to use Synthmaker, 1000 times easier than using a programming language like C or others.

If you can program C++, use the SDK or maybe try Synthedit.. that can be expanded by C++ modules.

jordanmccuaig · 10 May 2012

Hi there, thanks for your reply... How would you go about creating a reverb that is slightly more advanced than the freeverb module? I would like pre-delays and time syncing and presets...

CoreStyler · 10 May 2012

jordanmccuaig wrote: Hi there, thanks for your reply... How would you go about creating a reverb that is slightly more advanced than the freeverb module? I would like pre-delays and time syncing and presets...

Preset's are managed by Preset module. The preset's uses wireless links (internal) and should they work automatically with the tooloboox effects.

There are many people that has make reverbs. But to make a cool reverb and "engenieered" you should know how a digital audio process can be an algorithm that emulate a reeverb. You study at University, so maybe you know the math terms of that. 😉 I can't support you so much with DSP since my knowledge of DSP and Math too is too basic. 😉 But many people here, like trogluddite can help you really more. (he had make an improved reverb and a custom reverb). I'm the mantainer also of synthmakers.net, a new project, that has a good DB of modules.. but at the moment is little. (is online from just some weeks). http://synthmakers.net/downloads/viewdo ... rogz-tools

Another thing. Try to start from the Adavanced reverb, by downloading the analog toolkit.

trogluddite · 10 May 2012

CoreStyler wrote: But many people here, like trogluddite can help you really more. (he had make an improved reverb and a custom reverb).

He he, cheers mate - but lets not get too carried away. What I did there was to adapt and optimise some code already made (and earlier optimisation process) by other people. I suppose you could say that 'code bashing' is my thing - to make a reverb from scratch, I wouldn't have a clue!

jordanmccuaig wrote: I hope this isn't too vague and I can get some help.

And I aplogise if this reply also seems a little vague... There is a lesson also in what I just said above - for the kind of projects that have been mentioned there is nothing new that needs to be invented. That is not a criticism - in fact, I would say that the biggest part of DSP design is to know how to use and adapt the things invented by the folks who came before us. Even when programming using C++ etc., huge amounts of code will rely on linked libraries (e.g. VST SDK) developed by a multitude of other people.

And I would (did, in fact) tackle the SM learning curve that way - for example, if the stock knobs/switches etc. have all the functions that you need, then do not even try to understand them just yet. I would imagine that your course tutors are aiming for students to get an understanding of how DSP algorithms are implemented in practice - and that part, the actual 'core' of the DSP should be the focus of the most attention. So, I agree with Corestyler's advice - if the code module is closest to what you already understand, tackle that first, and aim your forum questions in that direction also. Then get the core effect algorithm working first - you can 'prove' and 'improve' that part of your understanding even with the crudest of user interfaces. More importantly, the stuff you learn doing that will be incredibly useful even if you decide to change to a different software platform at a later date.

When doing this, try to use the 'modular' nature of SM to your advantage. For example, in your study of DSP you may well have seen flowcharts and block diagrams demonstrating the 'flow' of processes. SM's audio modules will let you emulate these - so break down what you want to do into smaller units. For example to add pre-delay to a reverb - you do exactly that; take a delay module and plug it into a reverb module. The reverb module then breaks down into smaller units such as comb filters and all-pass filters. In fact, I often 'sketch out' the structure of a new plugin with completely empty modules - simply putting some connectors on them to get an idea of what signal will be where. That is the most important part of working modularly - what should go in, and what should come out of each part. A module is effectively a 'function call' or 'procedure' in regular programming - and just like in regular programming you can create and test each one in isolation before bringing them together. If you break your idea down enough, you will almost certainly find a module in the toolbox, or here on the forum, that will provide each little 'piece of the jigsaw'. Then you can learn more about the inner workings of each little block one at a time. If you build what you want at this smallest level, and then slowly add to it, you will have taken control of the 'structure' of your schematic - I think it will be easier to understand the 'structure' or modules this way than by trying to 'reverse engineer' another user's complex design. No matter the skill level, IMHO this is the always the best way to build a schematic. Making little bits in isolation can be a little frustrating because you want a new toy to play with ASAP, and the little bits on their own often don't sound like much! But it will make for much less 'brain ache' than aiming to make a working prototype of the whole thing all at once - I made that mistake many times at first, and found that it just leads to a lot of bug-fixing and re-building that really gets in the way of learning the core DSP skills.

Anyhow, sorry for such a long post, I hope it is some use for getting your project kick-started and getting some enjoyment out of SM. You can always be sure of getting help here as and when you need it. And don't ever worry that you are 'bothering' us with too many questions, or that anything is too silly to ask - everyone here learned SM that way (if you looked at the official 'documentation' you surely know why!!)

Warmonger · 10 May 2012

For me it's easiest to think about modules in terms of object-oriented programming. Some are similiar to each other - these are instances of one class (they actually are!). Others are nested - these are nested classes or composite objects. Every class or object performs the very specific task and feeds it result to another.

All the issues with threading and synchronization should be handled automatically by SM at basic level, you shouldn't bother.

In fact, in last semester I used SM as a base for three hardware projects on university - rapid prototyping and straightforward algorithm implementation.

jordanmccuaig · 10 May 2012

Hi guys, cheers for the feedback. I'm not required to code, but just use the components within SM to create approximately 4 synths.. I'm opting for the audio processing direction, as mentioned previously, delays, reverbs etc.. Naturally I have been looking at posted examples and trying to replicate them one way or another. I think the maths part of the process confuses me a tad, and I guess its just the organisational structure. Every time I think something has come together, I double click it and another module appears! Where does it end! haa

ChrisHooker · 11 May 2012

Hey, Jordan.

Where does it end? Where you need it to. lol ...It really just depends on how complicated the process is that you're trying to accomplish. What MIGHT be easier for ya - instead of looking at very involved, complex and specific PRE-MADE projects, where trying to figure out what was done and why could be confusing, try making some simple processes yourself, and you'll start to get the hang of it quickly.

For example, how about another VCA example (volume control) - Without delving into the code component, you can make this through a few primitives from the toolbox. You need a sound source (either from external input, or an osc, or even a wave player), a volume control with range 0-1 (you could use something like a knob, a float value, or a fader), a "stream multiply" component, and then your output. You just multiply the audio stream by the desired volume. Done. That's pretty simple math. An example of why a pre-built version of this might be more confusing: maybe they put a logarithmic taper on the control. It's not necessary, but might have been desired for that specific use. Start out simple though, and you'll quickly learn to identify the basics, then you'll recognize the extras quickly after that.

As far as distiguishing which modules can open further, one way you can tell is by the number of icons they have when you single-click on them. More than 3 (XNO), and they'll open further (these are called "Modules"). Just those 3, and it's a "Primitive" (the simplest component in SM, which cannot be broken down). Also, most modules (the ones that can open further) will have a semi-transparent grey box encompassing them (or just BE a semi-transparent rectangle), whereas primitives are opaque and have a drop-shadow.

When I was first learning, I read the User Guide (found in the Help Menu), and played around a lot.

If you want some tutorials, check out the wiki [old link]

Hopefully that'll be of some help to you. Once you get started with SM, it's hard to put down. It's just good ol' fun, like leggos, tinkertoys, construx, or erector sets for software! haha

jordanmccuaig · 13 May 2012

Another simple question.. starting to get my head around this a bit.. If my plugin is an insert plugin, ie an audio effect such as a reverb, is my input ASIO in? I assume it isnt direct sound as that would be for live input?

ChrisHooker · 13 May 2012

Actually, for plug-ins, you typically just want (at least one) mono in(s) and out(s). The plug-in won't typically be dealing with sound directly from the soundcard/interface, rather the audio will be routed through the host program first.

Direct Sound In / ASIO In are both for getting audio directly from the interface, just depends on what type of drivers you have.

Check out the User Guide and Component Reference for a deeper explaination.

jordanmccuaig · 13 May 2012

So simply two module ins? with the output going to direct sound??

ChrisHooker · 13 May 2012

Yup, two inputs to the module (mono type). Outputs can just be the same. For a strictly audio processing vst (like reverb), that's all you need. No Direct Sound.

As a test, you can make an empty module with the only contents being one mono in and one mono out. When you click on the module, you'll see the option to export as a VST.

There's a sample VST in the toolbox, just type in "VST" in the search box.

If you want to HEAR the plug-in while in SynthMaker, you can put a DirectSound Out or ASIO Out in your schematic, but I suggest you place it OUTSIDE your plug-in module, so it won't try to export.