GR-55 - Gumtown's GR-55 FloorBoard Editor

[philjynx]

I've just done another test (UM-ONE) connection, this time using a Win7 machine. Still only able to run the 2014 version. Anything beyond crashes in the already described way.

That only leaves the GR55 as a constant, I don't have another one to try.

As I said, I'm happy with the 2014 version of floorboard, so I'm moving on to other things.

If any of this has been useful to you Colin, that's great.

[gumtown]

Looking at your data capture,
 and I am wondering what the story is with the CC# looking data, as being 4 bytes, is not 'midi compliant"
 (the GR-55FloorBoard data filter only filters out 2 byte program change and 3 byte cc# controller data).
If the 4 byte controller data is getting into the software editor, then it will trip it up, as the software is looking to remove only 3 bytes of controller data from amongst the patch data return stream.

The difference between the 2014 and earlier versions of GR-55FloorBoard, and later versions, as far as midi /data handling goes,
 is the earlier versions would shut down the midi port in between data transactions, so the midi input port is restarted when the program is waiting on a data reply from the GR-55, while later versions keep the midi input port open continuously.

USB MIDI sent:length: 17 : F0 41 10 00 00 53 11 21 75 00 00 00 00 31 34 05 F7 (<-- data request to GR-55)
USB MIDI sent: B0 7B 00 01  (<-- 4 byte controller data ? ? ?)
USB MIDI sent: B0 79 00 01
USB MIDI sent: B0 7B 00 02
USB MIDI sent: B0 79 00 02
USB MIDI sent: B0 7B 00 03
USB MIDI sent: B0 79 00 03
USB MIDI sent: B0 7B 00 04
USB MIDI sent: B0 79 00 04
USB MIDI sent: B0 7B 00 05
USB MIDI sent: B0 79 00 05
USB MIDI sent: B0 7B 00 06
USB MIDI sent: B0 79 00 06
USB MIDI sent: B0 7B 00 07
USB MIDI sent: B0 79 00 07
USB MIDI sent: B0 7B 00 08
USB MIDI sent: B0 79 00 08
USB MIDI sent: B0 7B 00 09
USB MIDI sent: B0 79 00 09
USB MIDI sent: B0 7B 00 0A
USB MIDI sent: B0 79 00 0A
USB MIDI sent: B0 7B 00 0B
USB MIDI sent: B0 79 00 0B
USB MIDI sent: B0 7B 00 0C
USB MIDI sent: B0 79 00 0C
USB MIDI sent: B0 7B 00 0D
USB MIDI sent: B0 79 00 0D
USB MIDI sent: B0 7B 00 0E
USB MIDI sent: B0 79 00 0E
USB MIDI sent: B0 7B 00 0F
USB MIDI sent: B0 79 00 0F
USB MIDI sent: B0 7B 00 10
USB MIDI sent: B0 79 00 10

You could try a backup to file of your GR-55 system data and patches, Factory Reset the GR-55, then reload.
As the GR-55 has been know to occasional loose it marbles and do weird stuff.

But note that a backup to file through the editor is best,
 as the USB thumb drive binary backup is know to save corrupted data and reload the same bad data back in to the GR-55 (FYI for all GR-55 users).

I am wanting to make the software bullet proof, so am quite happy to pursue at resolution. 

[philjynx]

If the 4 byte controller data is getting into the software editor,

Wrong direction

Where it says "GR55 sent", this is what Jynx 3 got from its DIN input port attached to GR55's DIN output port.
Where it says "USB MIDI sent" this is what Floorboard sent.

The log is from the perspective of the bridge between the editor and the GR55 , it shows what is sent by the gr and fl.

I'll check to see what those four bytes are....

[philjynx]

Here's a code snippet from my bridge software so you can see how the message is constructed. Remember, in this discussion a usb message is one coming from GRFloorboard.

Code Select Expand

if (usbMIDI.read())
    {
      // get the USB MIDI message, defined by these 5 numbers (except SysEX)
      byte type = usbMIDI.getType();
      byte channel = usbMIDI.getChannel();
      byte data1 = usbMIDI.getData1();
      byte data2 = usbMIDI.getData2();
      byte cable = usbMIDI.getCable();
      if (cable == EDITOR_CABLE)
      {

        if (type != usbMIDI.SystemExclusive)
        {
          // Normal messages, first we must convert usbMIDI's type (an ordinary
          // byte) to the MIDI library's special MidiType.
          midi::MidiType mtype = (midi::MidiType)type;
          GR55Midi.send(mtype, data1, data2, channel);
          debugMidiMessageWithNarrative("USB MIDI sent: ",mtype, data1, data2, channel);So B0 7B 00 01  is
type : control message
controller : 7B
value : 00
channel : 01

79 = Reset All Controllers. 
7B = All Notes Off.


The messages you quote are from 20140810FloorboardSession.txt which is the log of the only version of Floorboard that I have that works.

In your 2014 version you were using an older version of RTMIDI which spewed out those two messages to ALL channels every time a port was closed, hence that stream of messages.

[gumtown]

So B0 7B 00 01  is
type : control message
controller : 7B
value : 00
channel : 01

controller messages should be constructed
B1 7B 00
B = controller type message
1= midi channel (B0~BF = channels 1~16)
78 = controller
00 = value.

But I think that is the way your code is reading midi data, and not sending in that format.

GR55Midi.send(mtype, data1, data2, channel);

or is it ?
If sent as 4 bytes to the GR-55, it will only see it as midi channel 1 and a spare un-allocated byte on the end.

https://www.songstuff.com/recording/article/midi_message_format/

[philjynx]

controller messages should be constructed
B1 7B 00
B = controller type message
1= midi channel (B0~BF = channels 1~16)
78 = controller
00 = value.

But I think that is the way your code is reading midi data, and not sending in that format.or is it ?
If sent as 4 bytes to the GR-55, it will only see it as midi channel 1 and a spare un-allocated byte on the end.

https://www.songstuff.com/recording/article/midi_message_format/

The MIDI library and usbMidi libraries are stock libraries neither authored or modified by me. Both have similar if not idendical methods to access received messages and to send messages.

So B0 7B 00 01  is
type : control message
controller : 7B
value : 00
channel : 01

Above is a representation of B1 7B 00 it is the  intermediate values extracted during the process of bridging the two MIDI streams.

The status byte B1 has been split into two nybbles - by the midi library, not by any code I've written - (Represented as bytes one and four in the log file).

The libraries take care of the assembly and disassembly of this data.

Both libraries make the 'send' function public primarily to facilitate having a generic send regardless of the message type - PROVIDED IT'S NOT A SYSEX MESSAGE




In the code quoted earlier, you can see the data being extracted from the incoming 'usbmidi.read' message and later sent using 'GR55Midi.send' minus the virtual cable number.

GR55Midi.send (again, not written by me) deals with putting that data into sensible order to transmit.

With the exception of sysex messages, the log file does not echo the messages. It tells you what has been reported by the midi library which is:

The type of message.
The first data byte of the message.
The second data byte (if applicable the library will return 00 otherwise).
The channel.

3 bytes read is transformed into 4 bytes reported and then when sent they are massaged back into the correct shape by midi.send().

Here's the entire code from my Jynx V3 that handles the bridging

void loop()
{
  if (myButtons.getExclusiveStatus())
  {
   
    if (GR55Midi.read())
    {
      // get a MIDI IN1 (Serial) message
     
      byte type = GR55Midi.getType();
      byte channel = GR55Midi.getChannel();
      byte data1 = GR55Midi.getData1();
      byte data2 = GR55Midi.getData2();

      // forward the message to USB MIDI virtual cable
      if (type != midi::SystemExclusive)
      {
        // Normal messages, simply give the data to the usbMIDI.send()
        usbMIDI.send(type, data1, data2, channel, EDITOR_CABLE);
        debugMidiMessageWithNarrative("GR55 sent:", type, data1, data2, channel);
      }
      else
      {
        usbMIDI.sendSysEx(GR55Midi.getSysExArrayLength(), GR55Midi.getSysExArray(), true, EDITOR_CABLE);
        debugSysexWithNarrative("GR55 sent:", GR55Midi.getSysExArray(), GR55Midi.getSysExArrayLength());
      }
    }

    if (usbMIDI.read())
    {
      // get the USB MIDI message, defined by these 5 numbers (except SysEX)
      byte type = usbMIDI.getType();
      byte channel = usbMIDI.getChannel();
      byte data1 = usbMIDI.getData1();
      byte data2 = usbMIDI.getData2();
      byte cable = usbMIDI.getCable();
      if (cable == EDITOR_CABLE)
      {

        if (type != usbMIDI.SystemExclusive)
        {
          // Normal messages, first we must convert usbMIDI's type (an ordinary
          // byte) to the MIDI library's special MidiType.
          midi::MidiType mtype = (midi::MidiType)type;
          GR55Midi.send(mtype, data1, data2, channel);
          debugMidiMessageWithNarrative("USB MIDI sent: ",mtype, data1, data2, channel);
        }
        else
        {
          GR55Midi.sendSysEx(usbMIDI.getSysExArrayLength(), usbMIDI.getSysExArray(), true);
          debugSysexWithNarrative("USB MIDI sent:", usbMIDI.getSysExArray(), usbMIDI.getSysExArrayLength());
        }
      }
    }
    myButtons.processSwitches();
  }
  else

It works fine, honest!
If you're curious about myButtons.getExclusiveStatus() , Jynx V3 goes into one trick pony mode to allow unimpeded MIDI traffic for floorboard to do its thing. In one trick pony mode processswitches() only looks at the editor footswitch and ignores the other 31 switches. All other functions of Jynx V3 are out of action in this mode.

Besides, I get exactly the same behaviour with:-

PC <-> USB <-> GR55
PC <-> UM-ONE <-> GR55

In those cases there's nothing of my making involved in the process.



I hope I'm going to get a beer out of this!

so much for

As I said, I'm happy with the 2014 version of floorboard, so I'm moving on to other things.

If any of this has been useful to you Colin, that's great.

You could try a backup to file of your GR-55 system data and patches, Factory Reset the GR-55, then reload.

I shall try the above and do ONE more test for you. I'll get Jynx V3 to log the session and I'll also put the UM-ONE in series first monitoring from Jynx V3 to the 55 and then monitoring from 55 to Jynx V3 and get MIDI-OX to log those sessions too.

I'll test the 2014 version and the ' 30 Oct special version for Philjynx'

I hope I'm going to get a (virtual) beer out of this!

so much for

As I said, I'm happy with the 2014 version of floorboard, so I'm moving on to other things.

If any of this has been useful to you Colin, that's great.

[philjynx]

Whodathunkit?

I was able to back up my patches using the 2014 Floorboard.
I was not able to backup the system with that or the ' 30 Oct special version for Philjynx'  version as both crashed during the process, neither producing a backup file.

I factory reset the GR55 and (you've guessed haven't you?) ' 30 Oct special version for Philjynx'  works properly with it as does the 2014 version.

In light of this, the comprehensive tests with logs that I had planned to do are not going to happen.

It would seem that a new set of marbles was what was needed.

I am wanting to make the software bullet proof, so am quite happy to pursue at resolution. 

I suggest that some more error trapping is needed, a graceful way of handling things not going according to plan.

[Elantric]

GR-55 is a device which responds positively with a full factory Reset 4 times a year

[gumtown]

This weeks jigglery-pokery has now lead to a new update "Version 20231101" (01st November 2023 - version number is the date backwards YYYMMDD)

So it seems that as well as adding extra data filters,
 I have now managed to get the editor to read the patch changes from the GR-55 pedals and from the S1/S2 switches,
 or from external midi, to detect the changes from the GR-55 (so long as Send PC is enabled) and load in the required patches into the editor.

All a new display method of incoming data from cc# controllers and EXP pedal, and guitar midi (so long as that is enabled in the GR-55).
There are many other refinements in there too.

The Windows version is updated, and the MAC OS and Linux versions will follow in the next few days.

Enjoy !!

[gumtown]

It just keeps on getting better !!

So I have been busy over the past few weeks updating the GR-55FloorBoard editor software, there will be a series of updates over the next few weeks, currently the Windows version is at 20231104 (4th November) with the Mac and Linux versions following over the next few days.
Some updated features are:
New scaled knobs and layout,
Recognition of patch changes on the GR-55 by wheel, midi, or pedals, and patch loads in, patch tree indication updated,
Better data filtering so guitar to midi can be enabled while editing.
Received data events shown/scrolled on bottom status bar.
Better patch write sequence, where the GR-55 and patch tree indication are updated on patch write into the GR-55.

There could be more features added, also looking for user suggestions on any other feature ideas to add.

Download here: (remember Mac and Linux versions are yet to be updated in a few days)
https://sourceforge.net/projects/grfloorboard/files/GR-55/

[underrock]

Thank you for the latest updates, the big dials are especially easy on the eye.

[acousticartist]

Hey Gumtown! I tried to donate via PayPal link in the help menu and I get the following: "This organization can't accept donations right now."

Your work is totally worth supporting and and by this time you deserve a "lifetime Achievement Award" for your contribution to the MIDI guitar world.

[gumtown]

You most likely have an older outdated version,
the latest is 20231106 (6th Nov 2023) with a new link.

uninstall the old one, download here:
https://sourceforge.net/projects/grfloorboard/files/GR-55/
and install/run :-)

Latest added feature is. . . . PCM Synth Copy (1>2 and 1<2)      

I think the editor workflow is 'working' better now..

[acousticartist]

Thanks, that worked. I guess my mistake was not trashing the old version before installing the new one.Donation sent!
Don

You most likely have an older outdated version,
the latest is 20231106 (6th Nov 2023) with a new link.

uninstall the old one, download here:
https://sourceforge.net/projects/grfloorboard/files/GR-55/
and install/run :-)

Latest added feature is. . . . PCM Synth Copy (1>2 and 1<2)     

I think the editor workflow is 'working' better now..

[gumtown]

A couple of screen capture pictures to brighten this page.
This is a PCM Synth editing page 1 of 2.


and page 2 of 2.


A few of the controls have been fixed, notably the LFO 1 & 2 now have the OFF position included,
 and that PCM 1<>2 copy button.

And highly recommended to update to the latest version (un-install the old one first).
as of today, the latest is built 6th November (20231106) Windows, Mac OS, Linux.
from here:
https://sourceforge.net/projects/grfloorboard/files/GR-55/

[Ismellelephant]

That is a bit of a red flag, the current version is generally not compatible with Windows Xp, and the oldest version which do run on Windows Xp will generally not run too well on Windows 10/11.

Which version of GR-55FloorBoard are you running @Ismellelephant ?
 

Thanks for the reply. On Win 10 it is Qt version 5.15.2 on Win XP 4.8.1

[gumtown]

I tried using the GR Floorboard Editor on windows 10. I see GR55 for midi in and out but for some reason I get this error " Patch data transfer wrong size error or data error" I also get "not connected". It still works fine on a old XP machine. I uninstalled on Win 10 and reinstalled and got the USB Win 10 driver from Roland, still getting the same error. Am I doing something stupid? Thanks for any help.

The GR-55 has been identified as having data corruption issues occasionally, and requires
1:) backup of user patches and system/global settings to file using an editor or librarian (not using the USB side port backup, as that copies and reloads the corrupted data).
2: Initiate Factory Reset of the GR-55 (in the GR-55 menu far right side)
3: reload the patch backup and system settings into the GR-55.

Then the later versions of GR-55FloorBoard will work with Windows 10/11

Not sure on which version you are running on Windows XP (version is a 8 digit reverse calendar number),
 but as you quoted Qt version 4.8, I haven't used that since 2012-ish, so a very old version of GR-55 FloorBoard.

[Ismellelephant]

The GR-55 has been identified as having data corruption issues occasionally, and requires
1:) backup of user patches and system/global settings to file using an editor or librarian (not using the USB side port backup, as that copies and reloads the corrupted data).
2: Initiate Factory Reset of the GR-55 (in the GR-55 menu far right side)
3: reload the patch backup and system settings into the GR-55.

Then the later versions of GR-55FloorBoard will work with Windows 10/11

Not sure on which version you are running on Windows XP (version is a 8 digit reverse calendar number),
 but as you quoted Qt version 4.8, I haven't used that since 2012-ish, so a very old version of GR-55 FloorBoard.

Thanks gumtown I will give that a shot. I am guessing Factory Reset means I loose any changes to patches I have made over the years?

[gumtownadmin]

Thanks gumtown I will give that a shot. I am guessing Factory Reset means I loose any changes to patches I have made over the years?

As per step 1, save your user patches to file before the reset.