Shruthi-Editor v1.03 (Windows, Linux, OS X) (updated 29.05.2016)

What it can do:

  • Edit patches/sequences up to (and including) firmware version 1.02.
  • Remotely change patch/sequence options on the Shruthi.
  • Load/save patches/sequences from/to disk as SysEx.
  • Fetch/send patches/sequences from/to the Shruthi.
  • Changes made to patch options on the Shruthi change the settings of the
    editor.
  • Generate random patches.

Known issues:

  • Receiving LFO 1/2 rates per CC (used by firmware version 1.01 and 1.02) is
    not optimal, but it should map to the Shruthi’s values.
  • Filseclab (at least versions from Jun 2015) flags the Windows binary compiled
    by gcc as Packed.NSAnti.b.fomm.mg; the 43 other scan engines used by Metascan
    don’t detect anything. This is called a false positive. The Windows
    binaries provided on github (starting with v0.23) are compiled on Linux using
    MXE and are uploaded on Linux.

19.04.2015: The new version finally supports the latest firmware versions and all filter boards.
28.04.2015: Version 0.22 adds a sequence editor.
18.05.2015: Version 0.23 adds a patch/sequence library.
17.06.2015: Version 0.24 fixes a rare crash and some internal issues.
19.10.2015: Version 1.00 fixes the OS X build problem and some internal stuff.
29.05.2016: Version 1.01 fixes some midi channel related problems.
29.05.2016: Version 1.02 updated to RtMidi 2.1.1.
06.06.2016: Version 1.03 updated configuration file location/new mxe version for Windows binary.

Screenshot
Windows Binary v1.03
Source Code v1.03
Github Repository

Please provide feedback if you use the editor: Does it work? What doesn’t work? If possible include operation system, Shruthi firmware version and connected filter board.

I’m not able to provide up-to-date Mac OS X binaries, because I don’t have access to a computer that uses it.

The Mac OS X binaries for the previous version and more informations (e.g. why I don’t provide Linux binaries) can be found on the releases page on github.

Informations about compiling are in the README. If you want to know anything else, please read the README, too.

Have fun.

Some general troubleshooting instructions:

  1. Is the editor set to the right midi devices? Shruthi->Change Midi Ports
  2. Does the editor display “MidiIn: ready. MidiOut: ready.” on startup or change midi settings?
  3. If you change a value in the editor, is it changed on the shruthi?
  4. If you change a value on the shruthi, is is changed in the editor?

Changes: At the bottom of the README file on Github.

AWESOME Thanks a lot!

Cant wait for the OSX Version…

GREAT, GREAT, GREAT…

Thanks a lot…will have a try on linux as soon as tomorrow…

cool! runs even on my computer!
now i can check if i’ve fried my usb interface…
many thanks

Great work Manuel! I have just tried this quickly on Ubuntu Natty 32 bit and it compiles fine (using libportmidi version 200 and libqt4 version 4.7.2) and it runs however, there seem to be a few problems:

1. “Load patch…” does not seem to work with the supplied .sp patches. (Randomise and reset patch do work though).
2. Sending the patch doesn’t seem to work mostly and the app crashes with “PortMidi found host error…
Operation not permitted
type ENTER…” if run from the terminal
3. Sometimes the app segfaults.
4. “Fetch patch” does not work at all.

Any ideas? Is it something to do with my MIDI interface do you think?

1. I’ve accidentally disabled loading and saving when I deactivated the debugging messages. I’ll upload a new version. Done.
2.+3. I have only tested it with portmidi 217, portmidi 200 is outdated since october. Please try updating to 217.
4. Does midi work at all? When you change a dial on the editor, does it change the value on the shruthi and vice versa?

does the editor also display changes that are made on the Shruthi?
i’ve probably wrecked my usb-midi interface yesterday, realtime changes from editor to shruthi works fine though.

also initialize a patch doesn’t get through to the synth, neither fetch (if that’s supposed to copy the patch from the synth)
but that could be related to my midi interface too.
gotta find out what’s happened.

Reset patch isn’t supposed to go through to the shruthi, it only sets the editors patch to init. You have to press send patch, if you want it sent to the shruthi.

that doesn’t work too. crap, troubleshooting time, the whole midi in is dead apparently too.

If your computers midi in doesn’t work, you should still be able to send patches. What does it say on the status bar, when you start the editor? You set it to the right devices, didn’t you?

yes, the problem is i somehow damaged my gm5x5x5 usb-midi. while uploading some firmware all midi ins failed to work one after another, maybe the device that was connected to it went into trouble… changing the optos didn’t have any effect, and as the out just works partially i think i damaged the chip.
so as long as i can’t find a new one i’ll rather stick to playing around with the realtime tweaking. that works fine.
thanks for the help!

ah yes, the status bar says both midi in and out are ok. i’ve set the proper device too.
but i know the in has problems as i couldn’t get feedback from my (midibox) core module after massive flood of midi input, that didn’t even stop when i switched off the core. so there’s definitely something wrong with my hardware.

have to try it! ANYWAY MEGA THANKS FOR SHARING :slight_smile: Will compil it for mac os nowwwwwww

will try lol

Compiling portmidi 217 for Ubuntu was a pain, :S but now your editor works coooool! :slight_smile: Thanks very much for sharing. My computer is still complaining a bit:
On the first couple of tries, the editor was not sending changes in real time however, it does so now and has done for every subsequent execution. Changing parameters on the Shruthi does not reflect in the editor though.
The “Fetch patch” option still doesn’t work :( run from the terminal it reports “Invalid sysex footer.” It seems that perhaps MIDI from the Shruthi is not getting through.
It has segfaulted once on me but I think that was because I changed the MIDI settings in the editor and then closed it because it wasn’t doing anything.

Are you able to provide a sample of what the four included patches are supposed to sound like? The three drone patches make a sound as soon as they are sent to the Shruthi without me playing any notes and the bitbass one has a very high resonance even at 42.

… it is such a useful tool so thanks again.

I am going to try to make an Ubuntu package of portmidi 217 and will post it here when I do…

Your midi input doesn’t seem to work right.
Please add:
for (int i=0; i<len;i++)
qDebug() << i<<":" << sysex[i];
to line 294 of lib_patch.cpp, recompile it, click on fetch patch and post the text that gets printed to the console. The first ten and last ten lines should suffice. It should be something like:
0 : 240
1 : 0
2 : 32
3 : 119
4 : 0

193 : 2
194 : 247

I don’t have samples of the patches and I can’t record at the moment, but I think you are hearing the right things. The patches are the result of the randomize function. I’ve saved the first few results that didn’t sound like a tractor.

Tractor noises LOL…

0 : 240
1 : 0
2 : 32
3 : 119
4 : 0
5 : 2
6 : 1
7 : 0
8 : 0
9 : 1
10 : 0

57 : 0
58 : 0
59 : 6
60 : 0
61 : 0
62 : 0
63 : 0
64 : 0
65 : 247
66 : 0
Invalid sysex footer.

After that, the editor stops working entirely. Closing the editor and restarting it does not make the editor start working again either. Only a reboot of my PC fixes the problem. I can use the editor once as long as I don’t try to get data from the Shruthi but as soon as I do, it locks the MIDI bus and/or portmidi drivers (or something).

The second time I run it and try to fetch or send patches (when nothing happens), when I close the editor I get a segfault:

* glibc detected* ./shruthi-editor: munmap_chunk(): invalid pointer: 0x08588748 *****
= Backtrace: ===
/lib/i386-linux-gnu/libc.so.6(+0x6b961)[0x71d961]
/lib/i386-linux-gnu/libc.so.6(+0x6c10e)[0x71e10e]
/usr/lib/libasound.so.2(snd_seq_close+0x45)[0x5e10d5]
/usr/local/lib/libportmidi.so(pm_linuxalsa_term+0x2a)[0x846c19]
/usr/local/lib/libportmidi.so(pm_term+0x17)[0x846cec]
/usr/local/lib/libportmidi.so(Pm_Terminate+0x23)[0x8480fd]
./shruthi-editor[0x805d8cd]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x6c8e37]
./shruthi-editor[0x804d1c1]

and I get a corresponding few lines in my dmesg:

[ 89.884023] rawmidi drain error (avail = 3704, buffer_size = 4096)
[ 163.872131] show_signal_msg: 15 callbacks suppressed
[ 163.872136] shruthi-editor[1812]: segfault at 9000000 ip 001b53f9 sp bfaf0818 error 4 in libc-2.13.so[145000+15a000]

I have tried a separate MIDI interface and the same things happens so I don’t think that is the root cause. Both my MIDI interfaces are USB though, one being a cheap generic brand called ‘Mistar Midilink’ identified by ALSA as ‘TaHorng Musical Instrument’ and the other being an Edirol UA-101.

Maybe I should stick to Mike Roe Soft Wind Blows… :stuck_out_tongue:

That is really strange. I use an edirol pcr-m50 keyboard as midi interface. Perhaps the problem is the alsa version…

Can you install valgrind an run the editor in it, try to fetch a patch and upload the logfile?

I am beginning to wonder whether either my Ubuntu install is not optimal or the new Natty version is very buggy, either ALSA or libc. I don’t want to waste your time on this Manuel. I have the following Valgrind logs anyway:

First I compiled shruthi-editor with -g and -O0 flags as detailed in the Valgrind quick start guide. Valgrind was run with --leak-check=yes. The computer and the shruthi were booted fresh and the first time the editor was run, it did not spit out those sysex debugging messages. On the second run the sysex debugging messages were evident. I have linked both log files from these two tests. Valgrind1.log Valgrind2.log

I then compiled the shruthi-editor with the default -O2 compile flags and ran Valgrind twice again and the following links are the log files. Again, the first time no sysex debug messages were shown and the app segfaulted. The second time no sysex debug messages were shown either. Valgrind3.log Valgrind4.log

Since Olivier hasn’t provided a OSX Version, i did compile mine and it seems to be working great.
So i’d like to offer Manuel my compile (or others) for review. Please contact me off-list via mail