RPI - Intermittent delay sending Program Change to Katana

Started by philjynx, October 23, 2017, 11:06:40 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

philjynx

...

sixeight

QuoteWhat to you get if you "uname -r" on yours SixeEight?

4.4.11+

Redvers

I had the same issue, I had to find a working sd card and copy the details from the files. Google did not help.

sixeight

Maybe this will help:

https://www.dropbox.com/s/cgy4ypnyhkf0ucw/2017-10-24%20VCbridge.rar?dl=0

It is my image with VCbridge for the RPi model b÷. Ttymidi is also on it. Default debian user and password.

Not sure what will happen when you install it on a higher version RPi...

sixeight

It is a file of 275 MB, which expands to almost 4 Gb when you unrar it.

CodeSmart

Quote from: sixeight on October 25, 2017, 02:26:56 PM
It is a file of 275 MB, which expands to almost 4 Gb when you unrar it.
Just a reflection. These are insane amounts of code. I have only 64 kilobytes flash in the MIDX and 16kb is occupied by the serial MIDI bootloader, rendering only 48kb for USB stack, controls, mappings, filters and Katana bridge...and still got 2.5kb left  ;) and no dropouts...
Running it on only 16MHz.

Really a different world with Microchip controllers and coding everything bare bone. If I step up to something better I feel I just go for another larger Microchip device.
But I got more gear than I need...and I like it!

gumtown

Midi delayed changes have been known to occur when a midi feedback loop is created.
Some devices when receiving a patch change (P.C.) will send/repeat the same patch change to the midi out.
If the controller has a midi in>out loop connection, this creates a midi feedback loop.
When this is seen in the GR-55, it slows right down, and seemingly locks up for a while.

Not sure if the Katana sends midi patch change, or passes midi from in to out, but might be a consideration to look at.
Free "GR-55 FloorBoard" editor software from https://sourceforge.net/projects/grfloorboard/

sixeight

QuoteJust a reflection. These are insane amounts of code.

It is a full Linux installation with a small amount of code for the midi bridge.

QuoteIf I step up to something better I feel I just go for another larger Microchip

Maybe the Teensy 3.6 is something that will fit the bill, as it has connectivity for a USB host port.

sixeight

Quote from:  philjynx on October 26, 2017, 09:35:06 AM
Indeed it has a usb host port, but as yet there is no support for it - I don't fancy (nor do I have the skill) writing the library for that! Have to wait a while for that functionality.

The comment was made in reaction to CodeSmart's post. He should be able to fix it.  ;)
But the USB host library is getting a lot of attention now. Not sure if it works fully though...

QuoteIt's also only one host port, the Pi has four all ready to go (subject to the frustration that the current Linux doesn't work reliably with midi). Perhaps that'll get fixed soon. It has to be said, despite the unreliability with current Raspbian, you don't have to muck about with clock speeds to use 31250 MIDI.

I did have to change the clock speed, as 31250 is not supported by the RPi. But the procedure may differ for RPi version b+, 2b of 3.

sixeight

QuoteSo we have Teensy aconnected through the Pi to Katana - press any of the four test buttons (these send Program Change) and the Katana responds instantly most of the time  but not all of the time, every so often there is a delay of up to one second. So, using an older kernel is not the answer.

Do you have any other Boss/Roland device to test with?
I do not have a Katana.

vtgearhead

Is it possible that the low-level code on your controller is buffering outgoing messages?  I never experienced any noticeable delay on simple commands when talking to Katana from a Beaglebone computer (over USB).  Only the very large sysex updates paused and even for those we're talking maybe 10-20 milliseconds for the entire user area.

What order of delay are you seeing?  10ms, 100ms. seconds ??

vtgearhead

Are you using firmware v2 or v1?  It's possible they introduced a bug with v2.  I don't own a head, so no experience with 5-pin serial MIDI.  Since you are using an RPi, is there a reason you cannot talk to the head on USB?

CodeSmart

I've only talked to the Katana via MIDX->USB. It runs smooth as butter. Both V1 and V2.
Not tried 5-pin MIDI on the Head.
But I got more gear than I need...and I like it!

gumtown

Free "GR-55 FloorBoard" editor software from https://sourceforge.net/projects/grfloorboard/

CodeSmart

The board is based on two small 16-bit 3.3V Microcontrollers by Microchip:
PIC24FJ64GB002 running at 16MHz.
http://ww1.microchip.com/downloads/en/DeviceDoc/39940d.pdf

There's one USB Host in each controller, they talk to each other using a serial link. The software is written in C using the Microchip IDE and there's no operating system involved. Debugging and flashing using a PicKit-3




But I got more gear than I need...and I like it!

CodeSmart

Regarding the Katana Bridge it consists of a never ending loop scanning for incoming messages from the Katana. All SysEx are parsed and if it contains something useful, I keep a copy of the variable. Just a few realtime variables are used.

The loop also scans for incoming messages from outside the bridge, these are decoded and translated to SysEx and sent to the Katana. I may also send a messages to the Katana to request an update of the real-time variables.

If a request sequence consist of several SysEx messages especially for the FX Chain data manipulating, you must issue a short delay (a few ms) between the request and wait for the response. In other requests I have seen no need for delays.






But I got more gear than I need...and I like it!

CodeSmart

Quote from:  philjynx on October 29, 2017, 03:02:11 AM
I'll find another use for the Pi and look into an alternative USB link to the Katana - as I'm still not capable of soldering in those SMDs into the Katana, and as I get (rapidly) older working on this, I'll become even less able to solder anything much smaller than a domestic cat.

If the functionality of the Katana MIDI Bridge in the MIDX-20 is sufficient for your needs, but you find the package too expensive I could sell you just the board a little bit later (I don't have so many left right now).

Small series enclosure painting, milling, printing, clear-coating is costly...

But I got more gear than I need...and I like it!

CodeSmart

Quote from:  philjynx on October 29, 2017, 03:19:46 AM
Glad to hear you don't have many left, I'm assuming that's 'cause you're selling well!  :)

Nahh, the first boom has gone..now it's slow. But I don't mind. Production, testing, packing, shipping and paper work is not so fun. I'd rather develop only... I get enough food on the plate from a regular work.
But still it's fun some guys appreciate the thing :D

Good luck Philjynx
But I got more gear than I need...and I like it!

vtgearhead

Quote from:  philjynx on October 28, 2017, 01:38:28 PM
The Katana is v2 firmware.
The entire reason for purchasing the RPi was to talk to the Katana via USB-MIDI because the combo has no DIN connection, that's what I've been banging on about all this time! Look at the green stuff in my last post and look at the singular, one and only red bit.

For completeness, I'll put the V1 firmware back into the Katana and see if it makes any difference. No, wait! The V1 Katana doesn't have the midi assigns that I want, so there's that..... Luckily that occured to me while I was trying to find my copy of the V1 stuff, so I haven't done it.

I haven't tried my Beaglebone based setup with the V2 firmware yet, but will do so ASAP.  With V1 I have never seen the slightest delay in simple operations like PC. 

But, Robert's MIDX-20 has no issues with v2 firmware so whatever is going on must be related to software on your RPi.  Initially, I had a lot of difficulty with USB on my RPi Rev. B, FWIW.  Take a look at the setup hints I published here:

https://github.com/snhirsch/mustang-midi-bridge/wiki/Install

Pay particular attention to the configuration tweak in /boot/cmdline.txt (near mid page).

Might be worth giving that a try to see if solves your delay issue. 

vtgearhead

#19
Jack?  I don't use jack.  It's an installation dependency for one of the libraries, but I use ALSA sound for MIDI.

The misbehavior you are seeing is not a matter of "isn't fast enough", but rather something going wrong with the application level or transport level software.

gumtown

I see you mention using MidiOX,
some of my observations developing timing dependant midi software, midiOX seems to introduce a slight delay to midi transactions through your P.C. (when porting though midiOX).
Which does not appear until you stop using midiOX and use your software direct to the device, and wonder why parts of your midi data is missing.

Other observations with Linux in particular, sometimes random garbage is received (a byte or two), prefixed with midi data, and may require data filtering.
Possibly if the midi buffer has not been flushed from previous transactions (sometimes sending Hex &80 fixes that as a data suffix, if your midi handler does not already do this).
Free "GR-55 FloorBoard" editor software from https://sourceforge.net/projects/grfloorboard/

vtgearhead

Hey, great news man!  I ran into a lot of problems with flaky and slow USB between RPi and my Fender Mustang III v2.  I cannot take any credit for that workaround, though. Found it (possibly on StackOverflow) during a protracted session of Googling.  The Mustang USB interface didn't play nice with Raspbian when it was in auto speed mode.  Seems reasonable you ran into a similar issue with Katana on the far end.


CodeSmart

...my PIC stuff also operates at "full speed" 12Mb/s.

Glad it works for you now  :D
But I got more gear than I need...and I like it!

gumtown

Free "GR-55 FloorBoard" editor software from https://sourceforge.net/projects/grfloorboard/

gumtown

I have gotten a bit lost on this thread now,
but, what would happen if you repeatedly sent active sensing 0xFE back to it.
Free "GR-55 FloorBoard" editor software from https://sourceforge.net/projects/grfloorboard/