On 09/25/2017 10:11 PM, Tim wrote:
Hi, long time no speak, just an update.
Been a crazy busy year for me so far.
I haven't stopped coding though.
Many things to deal with this year - life, work, distros, hardware,
code breakage. They're always breaking somethin' upstream, eh?
I just checked in my months-long work so far (non-compileable ATM)
to a branch for safe-keeping, to get it off this SSD drive.
It's been a slow journey, sparked by Andrew's bug report about Panic!
but I have rewritten a lot of the midi engine.
I mean like (more) proper: Ring buffers on all threads talking
to drivers and each other. Complete proper isolation and decoupling
of our ALSA midi thread using ring buffers with the aim of allowing
it to shine and outperform Jack midi in cases of Jack audio having
large buffers (meaning latency).
External midi clock support: Gone is my old system of time-stamping
and processing events in terms of ticks if externally syncing or
frames if (normally) using internal tempo map. It's ALL frames
processing now, baby! The drivers only have to deal with frames now.
External midi clock support is now more accurate and doesn't miss any
starting notes if recording.
Graphical midi controls now update even if no driver is selected for
a port - what you see on the controls should now /always/ be the
same as what's on the midi automation graphs.
Many other changes, too much to go into now.
*** Work in progress.
Thanks.
Tim.
Hey !
In my "engine_fixes_2017" branch:
I just added support for sending/receiving LARGE
system exclusive midi messages. ALSA only, for now.
Typically, that means more than 256 bytes is now allowed.
I have successfully done a FULL program dump from my
1986 Ensoniq ESQ1 keyboard to MusE.
That's 8164 bytes !
Similarly, I have played back (chunked) the system exclusive
event and successfully written to all of the ESQ1's programs !
The ESQ1 transceives the whole sysex data in one go.
Whereas, my BOSS SE-70 Guitar Effects unit sends the patch
dump as many individual system exclusive messages. each
about 100-200 bytes. I guess they could fit it each patch
into 256 bytes or less. And yet, each patch on the ESQ1
takes only 204 bytes. Go figure.
So... The huge challenge that prevented me from doing this
/many/ years ago was that ALSA 'chunks' any incoming sysex
which is typically more than 256 bytes in length.
Similarly, YOU must chunk any data that you send otherwise
you risk overrunning ALSA's buffer.
If you ever tried large sysex in MusE, until now you got
an error courtesy of me that chunking was not supported.
That's gone now :-)
Challenges: When sending, you must carefully time when
each chunk is sent. I 'estimated' when the next chunk
should play based on the number of bytes and the fixed
standard 31250Hz MIDI buad rate in a 1-8-2 format
(MIDI specs say ONE stop but ALSA says TWO is common).
Then I added a small 5 millisecond gap between chunks.
(Some apps make that adjustable.)
MIDI specs say only realtime event types (from 0xF8 to 0xFF)
are allowed while any system exclusive is in progress.
That was tricky.
When receiving, you must 'collect' the chunks and combine
them later.
That was tricky.
I created a whole new memory manager system for it:
classes MemoryQueue and class SysExInputProcessor.
And class SysExOutputProcessor handles sending.
But class MemoryQueue may allocate :-(
I may switch to a global memory pool instead.
I already use a global pool for one instance of my
/other/ new class: Class LockFreeMultiBuffer.
This is a MULTI-WRITER ring buffer! And it, and my other
SINGLE-WRITER class LockFreeBuffer are both C++ templates :-)
(A modification may follow. Our ring buffer design has a
slight observed flaw - it has a 'size' member.
It is possible for the write/read pointer to NOT be
the same and size be ZERO. Meanwhile Jack's JackRingBuffer
implementation design calculates 'size' on the fly
from the DIFFERENCE in the write/read pointers,
eliminating any possibility of error.
And what about Jack midi large sysex support?
Well, work in progress, maybe transmitting will work, I'll see,
but with receiving it gave me one chunk then stopped.
I will try to debug the ALSA driver and maybe offer a patch,
but I suspect it may go deeper because of the design:
Like "All events must be normalized" ??
Meaning 0xF0 (sysex start) and 0xF7 (sysex end) must
enclose ALL sysex data sent in one cycle? No chunks then?
There is a proposed Jack sysex sub-system on their site.
Cheers.
Tim.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Lmuse-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/lmuse-developer
