<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<b>Hello Folks,</b><br>
<div class="moz-signature"><br>
<b>1- Problem -only- under GNU/Linux; i.e. here Linux Mint 20.1
(Ubuntu base) and Manjaro Linux 20.2 (Arch base)</b><br>
I have a new major MIDI issue with Purr Data 2.15.2 regarding the
handling of BIG Bulk Dump (not below +/- 100 bytes -but only- when
higher from +/- 100 up to few 10,000s bytes), and -only in one
way-; i.e. MIDI-OUT from Purr Data to the external equipment.<br>
<br>
Otherwise in both directions (receiving & sending):<br>
- Under Windows 10, MIDI Messages & SysEx data (up to few
10,000s bytes) are working pretty well,<br>
- Awa under GNU/Linux just for MIDI messages (notes, PC & CC,
etc.) and small Bulk Dump (less than +/- 100 bytes).<br>
<br>
I'm using the same:<br>
- PC / Laptop HP Pavilion DV8-1190ef (CPU Intel Core i7 4x2 @ 1,6
GHz - RAM 8 GB) - 11 years old,<br>
- YESXR (Yamaha Electone SysEx Recorder) project (pure MIDI - no
Audio/DSP) built with Purr Data v.2.15.2 under GNU/Linux &
Windows,<br>
- MIDI/USB I/Fs / M-Audio (MidiMan) MidiSport Uno (1x1) &
MidiSport 2x2 Anniversary (both class-compliant operation), and<br>
- Yamaha Electone HS-6 (MIDI organ but not GM compliant which is
not an issue for just SysEx Bulk Dump).<br>
<br>
My YESXR project is targeting the Bulk Dump management of Yamaha
vintage Electone HX/HS/US/EL Series (32x organ models marketed
between 1986 and 2001).<br>
<br>
<b>2- Under GNU/Linux when sending big Bulk Dump</b><br>
After a lot of tests and investigations, it seems to me there is a
kind of big bug somewhere between the [midiout] and the
OS-MIDI-PORT (i.e. before the MIDI/USB I/F). This is true under
both Purr Data 2.15.2 (with its default libraries) awa Pd Vanilla
0.50-2 (Mint) / 0.51-4 (Manjaro) using ALSA MIDI with patchbays
like QjackCtl 0.50/0.90 or Patchage 1.0.0/1.0.2 or AconnectGui
0.9.0.<br>
<br>
<img moz-do-not-send="false"
src="cid:part1.3C3CE13D.6441545C@free.fr" alt="YESXR SysEx-Out
Test2" class="" width="1920" height="1080"><br>
<br>
<b> Explanation & comments:</b><br>
In the above screen capture (Linux Mint 20.1), I'm sending back an
FMP (Full Music Programmer) Bulk Dump to my Electone HS-6.<br>
[print sx-out] is connected to the ouput of [seq] which is well
sending the ~ 19,000 bytes of the FMP file (see the console output
- checked line by line with no error message), but it's not
received by my Electone which freezes during this procedure (I
repeat -only- under GNU/Linux and not under Windows 10!).<br>
Helped by MidiSnoop (note: it's not displaying the SysEx's F0
& F7h), I was able to determine that YESXR was only able to
send the initial (small) Request-to-Receive "F0, 43, 70, 70, 23,
F7h" (43 70 70 23 - line #1 in MidiSnoop) to my Electone but not
the next FMP big Bulk Dump "F0, ..., ..., ..., F7h" (~ 19,000
bytes).<br>
Sending again something from YESXR unblocks the situation, e.g. a
burst of MIDI notes (using the YESXR's TEST MIDI Note button). But
this notes burst rather than starting as expected with 'Midi On,
Channel 1' is beginning with a 'SysEx Bulk Dump' (line #2 in
MidiSnoop) and then only sending the 'MIDI notes burst', like if
this (part of) SysEx was stored somewhere. In add this 'stored
somewhere Sysex Bulk Dump' is only 514 bytes rather than the whole
~ 19,000 expected bytes. It's very strange!<br>
Note that the [print] objects in YESXR are only used for debugging
purpose and are not part of the application itself.<br>
<br>
<b>3- Simplified test patch</b><br>
I have build a simplified patch of my YESXR just for testing
purpose and the issue is still the same under -only- GNU/Linux
when trying to send big Bulk Dump (receiving is still okay).<br>
And under Windows 10, this simplified patch is working as good as
YESXR for both receiving & sending big Bulk Dump (SysEx).<br>
<br>
<img moz-do-not-send="false"
src="cid:part2.A96C47A5.A8A86239@free.fr" alt="YESXR SysEx-Out
Test3" class="" width="1516" height="706"><br>
<br>
The above screen capture has been done under Windows 10 v.20H2.<br>
<br>
<b>4- Questions</b><br>
I'm mainly using GNU/Linux and much less Windows (but I have to
pay attention to it as the majority of PC users are still with
this OS). I cannot test under macOS as I don't own an Apple (to
much expensive for my wallet).<br>
<br>
<b> Q1:</b> Under GNU/Linux when sending big MIDI Bulk Dump, is
there a hidden conflict with an API or an API which is not working
properly / has some kind of limitations?<br>
<br>
<b>Q2:</b> Do any Purr Data / Pd Vanilla users have faced to such
kind of MIDI SysEx bug under GNU/Linux? Yes! And what was the fix?<br>
<br>
This new problem is really getting me crazy.<br>
Any help, suggestion and/or guidance are more than the welcome.<br>
Thanks a lot.<br>
<br>
<b>5- Cyclone - A side note</b><br>
Purr Data v.2.15.2 (with Pd engine 0.48-0) is using an outdated
version of the Cyclone external (a set of Pure Data objects cloned
from Cycling'74 Max/MSP). Purr Data still carries a very old
Cyclone v.0.2 (compatible only with ~ Max 4.0.x) which is more
than 5 years old and on its own is not yet fully ported to Purr
Data.<br>
Currently Cyclone is in v.0.5-5 (compatible with ~ Max 7.3.5)
released on November 25th 2020 (needs at least Pd Vanilla engine
0.51-3), so Purr Data is incompatible with it.<br>
<br>
<img moz-do-not-send="false"
src="cid:part3.781644E6.7A5A62ED@free.fr" alt="Cyclone External
History" class="" width="695" height="804"><br>
<br>
- - - - - - - - - - - - - - - - - - - -<br>
Best,<br>
<b>Joseph Gastelais</b><br>
- - - - - - - - - - - - - - - - - - - -<br>
</div>
</body>
</html>