Academic Planner

Bump?

Just a friendly bump. I received a sammichFM confirmation email over a year ago and haven't heard anything since. Did I somehow miss the train?

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.

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.

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.

Thanks for the info! I was not aware of the requests. I'll get started on a new Guru script using SysEx this week.

Ok, so I just went back and reread the MIDIbox SID V2 CC Implementation Chart text and saw this bit: "CC changes are non-destructive and won't affect the edit buffer. This isn't a bug, but a feature! Means: your edits on the Control Surface won't be overwritten by incoming CCs, but as an effect they won't be displayed on the LCD, and you won't be able to store changes made via CC as a new patch." So there is absolutely no way to save the changes made by a CC to a patch? Would I have to code my own sammichSID Guru script using NRPNs? :cool:

Hello all. I recently built a sammichSID and uploaded patches with great success. I now finally have time to edit patches of my own, but I'm running into several issues. I'm using a Guru script for Renoise that I found here: It works great and I'm able to change patch values with ease using an external MIDI controller. Everything is up and working properly on that side of things. However I am not able to actually save these changes on the sammichSID for the life of me. If I create a patch in Guru and I go to save "direct" on the sammichSID it will save whatever was there before the adjustments were made in Guru (if it was originally a blank patch it will save silence, etc etc). If I use "edit mode" on the sammichSID (Shift+down arrow) there is no saved change at all. The only way I can save adjustments to a patch is if I manually navigate and edit the patch by using the one knob on the front panel. :D Did I miss something in the manual about a particular setting? I've also tried the Ctlr editor with extremely buggy behavior, so this isn't the best option for me. Has anyone run into this?

Encoder fixed up upping to 2.042! Thanks!

Finished building the V3 sammichSID and ran into the same issue as Johey regarding the LCD pin difference (What was Wilba's original suggestion? I missed it!) and the same flaky encoder as q-p (NO fun to program from the front panel!!). These two sour points aside, I soldered a wire per Johey's suggestion and it sounds/looks great! Now if only I can do something about that encoder! Is it too late to jump on the final batch for a second one?

Same exact situation here! I'm worried these are gone for good.