Helm Synth Free Download
Joie Coffield
Just started learning prod, and I've been using the free Helm synth by Matt Tytel for pretty much everything sound design. I've used it basically as an alternative to Serum, which seems to be the gold standard.
Found out about the Vital synth yesterday though. Looks awesome, excited to learn it, but was wondering if it can completely replace Helm and be my go-to synth. Does Helm have anything Vital doesn't, and is it worth using Helm at all anymore?
Since I saw a tutorial on Sonic Pi controlling Helm I guess I was wondering if you could play synths from helm with a MIDI keyboard and bring that into Sonic Pi. This is the tutorial I am referring to:
Hi Eyebot
Yes it is perfectly possible to play Helm with a midi keyboard, and to bring the audio output into Sonic Pi. In fact I am currently working on a program to make it easy to select synths from Sonic Pi using midi cc commands and then to bring audio back into Sonic Pi.
How you connect it up depends on the platform you are using. It is slightly different on a Mac compared to on a Linux box or a Raspberry Pi
PS I wrote the tutorial you refer to above!
Helm is a free, cross-platform, polyphonic synthesizer with a flexible modulation system. Helm is open source and you are free to run it anywhere, study and change the source code, and redistribute exact or modified copies of Helm.
Absolutely brilliant synth and very little CPU usage on my old laptop. The presets are really good and the programming is quite easy, if you have a basic knowledge of synths. The GUI is great too. Well done!!.
Could we convince Mr. Ichiro Toda to join forces or ... could somebody develop a patch/preset conversion tool to convert Synth1 presets to at least similar .helm patches. I used to be a programmer and I believe this could be done. Then, it would be the leading free VST.
There is this package of Synth presets in VST3 format which seems quite readable. That could be used to convert them to .helm. I know this wouldn't work directly, but with some testing /and having this converter OS or configurable) we might get it to some level of usefullness :)
Hi there, this is a great synth, really. But I'm having an issue with the arpregiator, it's out of sync (VST) but the tempo is locked correctly to the host tempo, and it slows up and down when the master clock does so. Only, not the correct tempo. Did anyone else notice this?
Anothe questio/issue: how can I use program changes over midi? (VST version in a host). I can only change the first 15 or so by midi, I have no idea how to access the other ones. The file structure introduces a non-existent (in the MIDI specs) level we have banks-then folders-then presets. When I manage to change presets it does actually call the first 10 in the first folder of the first bank, the a couple more in the second folder and that's all. I can't change banks by MIDI either. Any thoughts? Apert from that, I reeally like this synth. It's powerful.
He could have just added a chorus effect at the end of the synth chain & called it a day, but there is nothing quite like Roland synth chorus. He could have just added an EQ instead of sampling each brilliance setting. He could have just recorded long samples & hoped no one played until the end of the sample, but instead he spent a massive amount of time creating seamless loops for each note for each variation.
Sonic Pi is extremely versatile. Not only can it produce sounds itslef using built in synths, but it can also send and receive midi singals, and send and receive OSC messages. It is based on teh Ruby language, and you can also use (with care) many Ruby commands in addition to those in the official Sonic Pi language detained in the help files.
Probably a couple of years ago I first came across Help and have used it with Sonic Pi, but I wanted to see if I could strealine the setup, particularly by allowing Sonic Pi to choose the current patch selected on Helm. It took a bit of playing around, and looking at the helm code to work out how to send midi signals to achieve this. In fact you have to send three signals in succession. The first is to midi control 0 with data giving the bank number. This specifies whether you are using Factory Presets, User Presets, or another collection altogether. Each of these sections is held in a separate folder on the computer. In this case I am only concerned with the supplied Factory Presets, which has a bank number of 0. The program could be used with a different bank instead, or with a little more modification to several alternative banks. The second signal is to midi control 32 and specifes the sections within the bank: in this case arp patches, bass patches, SFX patches etc. Each if these are contained in a separate folder within the main bank folder. The final midi command is a midi program command which selects the patch number. This corresponds to the index position (from 0) of the alphabetical listing of patches within the section folder.
These commands are sent via the patch function I have defined.
This first defines the path to where the patch files are located, and then defines fa function :getList to read in the absolute file names from a specified folder, and to strip out the actual file name minus the .helm type suffix, and return these as comma separated string list. A second functions :getTypeList lists the folder names within the main bank folder (Factory Presets) and returns these as a list. (These are the types arp, bass,chip etc.)
With these two functions defined, code is run to populate individual lists l[0] to [8] for each of the types of patches, and to populate a separate list limits which holds the maximum index (from 0) to select the last patch in each list. Finally a list of the 9 separate patch lists is assembled in the list plist.
As you can see from the screen shot above, there are a lot of items on the TouchOSC interface. The main section has 57 yellow labels, which can be populated with the names of a patch. This is controlled by 9 similar (green) labels, each containing the name of a type of patch. Behind all of these yellow and green labels there resides a grey push button area. When the table screen is touched on one of these labels, the button behind sends an OSC message from the tablet to Sonic Pi. This message has the form /helm/pxx for the yellow labels grey buttons, where xx is a 2 digit number from 00 to 56, and /helm/tPx for the green labels grey buttons where x is a number from 0 to 8. The Green labels are permanently displaying the patch categories for the Factory Presets, however the Yellow labels will have their contents changed depending upon the patch names for the current type selected. This means that they each have to have a separate name and osc address. These range from /helm/L00 to /helm/L56 In order to accommodate this large selection of address, I make use of that fact that Sonic PI can respond to incoming OSC messages with wild card matches, so that ONE live loop can deal with all the incomping /help/pxx messages, rather than 57 different ones! To enable this to be useful, I developed a function called parse_sync_address which lets you find out the exact address that matched the wild card(s) used.
To look at one example:
The live_loop :chooseScale, responds to an incoming OSC addressed to /helm/selectScale/*/1 The * will correspond to which PatternSelect button is pushed. This is then used to control a Ruby case statement, and according to the value of the star 1-5 it sets values for the note sustain and base note of the scale to be used and then calls the doLoop function mentioned above. This creates a name for a live loop selected by the first incoming parameter n in the call with value :name1 .. :name5. It also creates an associated flag :kill1 .. :kill5 (initially set to false) which will later be used to stop the live loop. It starts the live_loop running, using the current tempo value (which can be changed whilst the loop is running). The loop stops when it detects the associated kill flag has been set to true. The chooseScale live_loop generates the change in kill flag value because when a new pattern is selected, because of the toggle action of these switches a switch off value 0 will be generated by the previously selected switch which is then used to set the ill flag for the loop to be stopped.
Two further live_loops stopAllScales and oscKillScales cooperate to switch off all 5 live loops (assuming any are running), when the Stop Pattern or Clear All buttons are pushed. The latter also clears the contents of all the patch labels and the currently selected type.
The TouchSCreen template should be downloaded as index.xml You should then compress (zip) it and rename the resulting file thelmSelector.touchosc This file should be opened in your TouchScreen editor and then synced to your phone or tablet in the usual TouchScreen way. You should enable OSC and adjust the host address to match that of the computer running your Sonic Pi copy. Set the outgoing part to 4559 for Sonic Pi 3.1 (or 4560 for Sonic Pi 3.2dev or later). Set the incoming port to 9000, and note the ip address of your tablet or phone shown below. You should adjust the use_osc line in the program to match this information. In my case with my iPhone it was ip 192,1681.240 and port 9000.
I hope to write another article in the near future detailing how to loopback the audio from Helm (and similar software synths such as Qsynth) to the audio inputs of Sonic Pi, both on a Mac, and on a Raspberry Pi (or linux) box. (There already is an article about setting up Qsynth on a Raspberry Pi here). The former can either use the (rather expensive) Amoeba LoopBack utility, or the (free) SoundFlower add (although this does not seem to give the same performance). The latter can be achieved in Qjackctl.
EDIT just come across a new free program called BlackHole which makes it easy to loopback audio from Helm or qaynth on a Mac. See this link for details