new FOSS parameter editor for Roland Integra-7

[shimpe]

Hello,

As a Linux user, I was dissatisfied with the lack of tools supporting the editing of Integra-7 parameters. Consequently, I decided to develop a tool myself during my summer holiday, with the additional goals of learning some C#, async/await programming, and AvaloniaUI. I believe I have made a promising start, with all documented presets and parameters now exposed, editable, and observable[*]. However, librarian functionality has not yet been implemented, and there is certainly room for improvement.

The user interface is currently quite basic, organizing and presenting all parameters as laid out in the SysEx documentation. I have not attempted to regroup these into more user-friendly views (and would need assistance for such an endeavor). This is alpha-quality software: expect bugs and limitations. However, if you are comfortable compiling software yourself, you are welcome to try it out. Your mileage may vary, but using my tool, I have already been able to get more out of my Integra-7 than ever before.

At this stage, no binary builds are available. You will need to be comfortable with compiling the software yourself. The software uses a GPLv3 license, and is written in C#, .NET 8.0 using the AvaloniaUI (XAML-based) toolkit. I am utilizing a combination of Visual Studio Code, JetBrains Rider, and gVim for development. While the software has so far only been tested on Linux, it should also work on Windows and macOS with minimal effort.

Please note that summer holiday is over (alas!) and I will not have a ton of free time, but I thought that perhaps a few people would be interested to take a look anyway. The place to get the code and to log bugs or discuss new features is: https://github.com/shimpe/Integra7AuralAlchemist

Have fun!

[*] Editable: Parameters can be changed in the tool's user interface and will be sent to the Integra-7. Editability requires that the Integra-7 is set up to receive Program Change, Bank Select and Exclusive (Menu -> System -> Midi -> Rx xxx). Observable: Parameters edited on the Integra-7 will be seen by the tool, and the user interface will update automatically to reflect the changes. Observability requires that the Integra-7 is set up to transmit edit data (which it is by default, but it could have been switched off in Menu -> System -> Midi -> Tx Edit).

[mj15003]

Me, as a Roland INTEGRA7 owner and Linux user at the same time, has encountered the same situation. Roland does not provide anything for Linux so I have built my own tool for parameter editing via MIDI called Integra7Frontend.

You can give it a try at https://github.com/mj15003/integra7frontend , if you are interested.

It can not control everything in the device for now, but the most of the most important it does.

It is written in C++, Qt and uses ALSA. For now you should build it yourself. It should not be difficult, It is a standard CMake project.

[shimpe]

That is supercool! (although at the same time, I guess there's a ton of duplicated effort - exposing all parameters in integra-7 took a lot of stamina ).
My tool also uses a wrapper around ALSA (at least on Linux; I'm using it through pipewire myself).

[mj15003]

It is interesting to know, that at least someone in the world has got the same crazy idea (of wasting time) Many months I was thinking I am totally alone and nobody else has ever seen my repository. My purpose was mainly to learn more C++ and Qt, not at the first place to have the tool. Sometimes it is more interesting building something than just using it. I had some previous programming experience with ALSA sequencer as I had built a few other command line tools. My tool has a lot of code but substantial part was generated with AWK directly from documentation (it was quite fun indeed) (it would be impossible pain to write it manually). The architecture is not the most optimal in comparison with your tool. Tone editing parameters still needs some debugging. I guess some things in fact do not work exactly according to published MIDI implementation and it needs some kind of trial and error approach.

[shimpe]

but substantial part was generated with AWK directly from documentation

oh wow that's really cool - I guess you converted the .pdf to text first (if so, how? copy paste?). I wish I had thought of that lol...

[Audiojunkie]

This is really great! I have wanted to buy a Roland Integra-7, but didn't want to be without the ability to edit it like I was with my Roland JV-1010, which to this day I still can't edit from Linux. I wish there were some Linux-based JV-1010 editors/librarians as well.

[mj15003]

but substantial part was generated with AWK directly from documentation

oh wow that's really cool - I guess you converted the .pdf to text first (if so, how? copy paste?). I wish I had thought of that lol...

yes, at first I converted PDF (MIDI Data implementation) to text with "mutool convert" and then I wrote AWK script accepting parameters to generate different parts of code on request, e.g. class templates, signals, slots, connections and even UI graphics in XML.

Then in it was just copy-pasting

[shimpe]

yes, at first I converted PDF (MIDI Data implementation) to text with "mutool convert"

Very interesting, I didn't know mutool. I tried it out and indeed it seems to do a decent job of converting the pdf to txt.
That probably could have saved me some time here and there. But then, it's really just the start of the adventure.
Even if you have all of the documentation in a readable format, there's a ton of stuff that is not in any (publicly) available documentation.

Things like which MFX parameter is used for every possible parameter in every possible algorithm, and dependencies between e.g. Delay parameters (a delay time sits in a different MFX parameter based on whether you selected Hz or Note delay type e.g.) took quite some time to map out by configuring the integra on the hardware and then analyzing the sysex msgs that came back from it (I did have some helper code to make this easier but I still had to go through everything manually at least once).

In the end I chose to group all the knowledge about integra parameters in a big parameters "database" (and a second database for start and offset addresses of parameters) from which everything else is derived programmatically: mapping parameter values of ui to integra, mapping of integra sysex back to ui, validation of min/max/enumeration values, dependencies between parameters, the complete ui itself, ... 90% of what you see and interact with is automatically generated from information in these databases.

The majority of problems I've encountered so far have been related to faulty entries in that parameters database (mostly me adding wrong entries - I'm sure there are some of those problems in there still) and, in all fairness, also quite a bit of multithreading problems - basically me learning how C# handles things (and, in some cases, also me being surprised at how tricky multithreading can be despite having some earlier experience with it).

[mj15003]

But then, it's really just the start of the adventure.

I definitely agree. Everything could not be generated and I have had to write some parts manually. Especially effects. Using the same approach and analyzing SysExes from Integra.

there's a ton of stuff that is not in any (publicly) available documentation.

Sure. And even the documentation is not always absolutely clear. For example, instrument and variation numbers mapping to SN Acoustic. Or for example I was not able to find anywhere a list of available PCM waveforms.

90% of what you see and interact with is automatically generated from information in these databases

This is why I think your tool has a better software architecture. My tool is mainly static and in some sense quite low level and bloated as it contains thousands lines of repetitive code. In the past I was thinking a little about making it more object oriented and UI generating on the fly but from that point in time it would require large overhaul and I was not willing to spend so much time with it.