I recently purchased a used Korg Ms2000 and am trying to get it to work with guru. I can get Renoise to play back midi notes via my midi interface, but sending a patch to the MS2000 seems to have no effect. Are there any settings I need to ensure are set / a mode I need to be in? Thanks for the awesome tool.
edit: figured it out, had to SystemEx on Page 4 Section D of the global settings to ENA.
Well, I’m afraid this is a bit messy right now, partly because I don’t have the time to work on Guru.
Grymmjack has made a Korg MS2000 sysex definition, and to get it to work he had to make some changes to the Guru source.
Unfortunately these changes have not been brought back to the official Guru code, so it’s floating around right now.
I sat down the other day and looked trough the modifications to see if I could just include them in Guru. Though they solved the ms2k problems, the solutions were a bit hacky and not generic enough for me to just include in Guru.
So, I started looking at the MicroKorg midi implementation, that is supposed to be the “same synth”. I discovered the MicroKorg did not have the same sysex implementation. So, in order to make Grymmjacks sysex implementation come be included in Guru I need help from someone who has as ms2k, maybe me and Grymmjack should work this out in a PM.
However, there is another solution. To make a MIDI CC implementation.
If you look at the ms2k manual, page 65, “Front panel knob/key control change assignments”. All these parameters are super simple to implement for the current version of Guru, and they are the same for the MicroKorg. So, by implementing this you would have basic voice using Guru. No sequencer and stuff, and not all parameters, but if it’s good enough for you? I actually started with the CC implementation, and you can take over, it will be simple, you just need a few hours.
Thanks to Cornbeast’s efforts and Dan P’s help in testing, I’m able to provide a synth definition for the Waldorf Blofeld. Attached to this post, you will find two versions: Waldorf_Blofeld.lua and Waldorf_Blofeld_small.lua. The first one will provide the best overview over all parameters while the second one tries to fit them into more tabs making it easier to use on smaller screens (laptops). If you are a proud Blofeld owner, please consider putting these to the test so we can try to get rid of any issues before this definition gets included into the Guru package.
For the delay time parameters, I needed to go over 127ms, so I used the value_callback=MSB function from the AN1X definition, and put it in utils.lua. I will post it from github.
The definition is quite large in pixels. If you are having trouble fitting it on your screen let me know, and I can send you a definition which is smaller, and have the performance parameters moved to another tab.
I tested it thoroughly let me know if you run into some quirks.
Keep in mind your DSS-1 needs to be in play mode to accept sysex parameter changes.
OK, I finished my M-audio Venom definition (only for the Single-Mode).
I referred and borrowed some code from the “Waldorf Blofeld synth definition file” made by Andrej Kwadrin, especially for the Modulation part and AUX part. Without them, I cannot finish this definition file. Thank you very much!!
Well, Venom has the official Vyzex and third-party Venomed Editor already. If compared with them, this Guru file is functionally inferior a little, especially there is no parameter-feedback from the hardware.
But still, It is a pleasure that I can edit synth parameters using Renoise GUI. It’s quite handy.
Also I finally can understand “what Guru is” basically. Thank you for the effort for such great tool. />/>
Is there a way to have Guru read in the current parameter data from the synth? That is, read the current patch and set the GUI appropriately? If not, I’m interested in adding such a feature. What would be the best way to go about it?
I’d really like to be able to tweak the built-in patches for my synth (Korg Prophecy), since I often want small changes to the filters, waveforms, etc, but the on-synth editor is completely terrible.
How would it do it when MIDI is only sent by a synth when it changes value?? Sysex (system exclusive) messages are much discussed through this thread though! Which is what synths etc do use to send their patch data over MIDI.
Yeah, Guru already uses sysex when necessary to change single parameter values on the synth, so that’s not an issue.
Most synths seem to have a sysex message that causes it to dump the parameters of the current patch. I imagine I could modify Guru to issue the relevant message, then save the response, somehow updating the GUI. The real question is whether such synth-specific functionality would fit well into the way Guru is designed, so I was hoping for some input from the creator on this. It would be very convenient to be able to tell Guru to load the current synth patch, and then make modifications from there using Guru.
Maybe not. I’ll try again. Sysex is part of the MIDI specification. Let’s say you have a synth that supports dumping/loading patch data via sysex messages. Guru could transmit the sysex message that says “dump your current patch” to the synth, which responds with a sysex message that says “here is the current patch data”. The synth def for Guru could, in theory, be programmed to accept that data and then apply the new values to the GUI, so that the GUI being shown would reflect the patch parameters.
Use of sysex by Guru is not an issue, since many synths require sysex messages to set individual parameters anyway, and Guru already supports this through its sysex templates.
The question is whether this is easy to do with the way Guru is currently set up, or if a lot of additional coding would be required. I suspect it’s not too hard, but I haven’t had a chance to examine Guru’s internals yet.
OK that makes more sense. Your initial post said “Is there a way to have Guru read in the current parameter data from the synth?” and my point is that nothing can passively read the state of all parameters of a piece of hardware via MIDI. It needs to be asked to send the information and then will do as SysEx messages. So this is all down to how the hardware unit has implemented it (some you can only do Bank Save/Restore for example, not the current Preset only) if it has implemented it at all.
But as Guru does preset management and some work has already been done with SysEx it shouldn’t be an impossibility to expand it to do this, assuming you can find the literature explaining how the Preset dumping is transmitted. But still you can not really ask the question in such sweeping terms as you have done so as you are talking about something that is not in the slightest standardised!