Trying to wrap my head around Sammich Sysex for Guru editor. Help?

[Academic Planner]

I decided to go ahead and try to write my own sammichSID patch editor for the GURU Renoise tool. There's one slight problem - I have no *$%$% idea what I'm doing. I'll explain my dilemma...

 

After some research I see that someone already created a GURU script for sammichSID. Great! It uses CC messages, but because the Sammich does NOT save CC changes to the patch buffer this does me absolutely no good. Not so great. So I see there is a Ctrlr panel for MidiboxSID/sammichSID. Great! It is buggy at absolute best. Not so great. I'm using Vista, and to put things simply, the Ctrlr panel does things at random or whenever it feels like. 

 

So here I am with a wonky knob on my Sammich due to overuse. A patch editor is absolutely necessary because I'm at a point where all I can really do is play notes and change patches.

 

I looked, studied, read, reread and tried to generally wrap my head around the MidiboxSID sysex documentation located here:

 

http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fsynthesizers%2Fmidibox_sid_v2%2Fdoc%2Fmbsidv2_sysex_implementation.txt

 

After hours (possibly days) of trying things out, I managed to get it half working. Even that is pushing it.

 

tl;dr - Someone please help.

----------------------------------------------------------

Here is what I know (or don't) so far...

 

Someone please correct me if I am wrong. The manual states that the sysex format for patch editing is:

F0 00 00 7E 4B <device-number> 06 <WOPT> <AH> <AL> <value_l> <value_h> F7

So let's say for example's sake I set the device number to "0" and ignore the <WOPT> for now. Let's also say that I would like to edit the volume on the lead engine. The manual says:

0x052 | [6:0] Volume (0-127, only most significant 4bits are used by SID)

Now this is where I'm completely ^&*$^*# up. The manual doesn't really make clear what [6:0] means. Furthermore, the manual says:

 

(<AH> = 0..3, <AL> = 0..7F) Patch address: (<AH> << 7) | <AL>

 

...in the description of the patch sysex layout. I have NO idea what this means and it's not really obvious (to a newb) where to find this information. As a workaround I loaded Ctrlr to see what it was sending in the MIDI monitor window for volume/lead engine control.

 

[f0 00 00 7e 4b 00 06 00 00 52 0f 07 f7]

 

...is what it was displaying, with the two value bits (0f, 07) changing, of course. I'm still confused on how this string relates to what was posted above. So I open GURU and enter:

 

sysex_message_template = {0xF0, 0x00, 0x00, 0x7e, 0x4b, 0x00, 0x06, 0x00, 0x00, "nn", "vv", 0xF7},
      number = 52,
      max_value = 127,

 

...where nn=number and vv=value. I've tried both hex/decimal values without success. Other times where I did get it to do something, GURU would jump 100 values or so, making it useless. So I please ask for some input on this. I'm determined to write out a new patch editor, but I cannot seem to get past the learning curve of sysex.

Edited April 30, 2013 by Academic Planner

[TK.]

Hi,

 

I'm very surprised that the Ctrl based panel doesn't work at your side, because it has been tested by multiple people.

And I feel demotivated to comment your questions when you are saying that it is buggy at absolute best

 

-> don't expect support from my side... I spent days to make this happen, but only get a stupid complaint from you.

 

My assumption is, that you are not using the right Ctrlr version which is linked at this page: 

 

Best Regards, Thorsten.

[Academic Planner]

Woah. I didn't mean to offend you and I apologize if I did.

 

I was simply stating that I've tried the Ctrlr panel on two machines with very, *very* sporatic behaviour. Sometimes there's no audio, sometimes I have to reboot Ctrlr for it to do anything, sometimes I have to choose tri, then noise in order to actually choose pulse, sometimes arp simply doesn't work, etc. Whether it's Ctrlr or my machines, I don't know, but the entire reason why I'm beginning my quest is to provide an alternative for editing the Sammich - considering the available options are not usable for me.

 

If you feel the need to not help, I respect that (I guess?) but please understand that I'm not throwing punches here.

[TK.]

An academical question: if a Ctrlr based panel, which has been tested by multiple people, doesn't work reliable at your side, how can you be sure that your tries with a self-written editor will work better?

 

However, much more detailed informations can be found in the Lua scripts which are embedded into the Ctrlr panel.

Alternatively you could have a look into the sources of the Java based editor: http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fjava%2F

 

These are two complete open source solutions which should give you enough details to implement a third one, if you really feel that this is the right way.

 

Best Regards, Thorsten.

[Academic Planner]

Thank you for the suggestion. I will look into these.

 

As far as the academical question is concerned, it looked like others had issues with Ctrlr in the thread for your panel. I'm not sure if *all* issues were resolved, as some of the users didn't come back with solutions from what I remember, but regardless - I don't really see how a third option directly involved in a tracker style environment would hurt anyway.

 

Perhaps I should have been a little more selective in my choice of words, but open source doesn't do anyone much good when the people with questions are attacked right off the bat.

[TK.]

Well, how would you react if you spent several days for the implementation of an editor, and then get the naive complaint that it doesn't work, forget it, your documentation doesn't help, and help me (now!).

I think that you expect too much from an open source project which has been developed during sparetime.

E.g. a documentation which even explains the very basic things (from my point of view). 

 

Do you see a way to clarify your issue on a more comfortable way for both sides?

 

 

 

 I'm not sure if *all* issues were resolved, as some of the users didn't come back with solutions from what I remember

 

You don't consider the history.

Several Ctrlr versions have been released by atom so far, there are dependencies between the panel and the Ctrlr release which have to be considered.

You mention that issues have been reported - based on which version, at which point of time?

You even haven't mentioned yet, which Ctrlr version you are using, under which operation system in which mode (Standalone, VST, AU)?

 

Your approach isn't academic!

 

Best Regards, Thorsten.