receiving sysex and storing it in ram

[EnzoF04]

Or are you trying to say that with a timer activated, the sending of request for sample dump message to the sampler and the following ACK messages sending to the sampler are within a timer dictated timeframe?

• This reply was modified 6 years, 8 months ago by EnzoF04.

[Possemo]

Your sampler does not send complete messages (starting with F0 and ending with F7) this could be a problem. I don’t know what Ctrlr does if a message is not completed by F7. Maybe it waits for F7 and keeps the bytes in the buffer. In this case you would have to send the acknowledge string “blindly”. I mean, just sendind the string (here a simplified syntax) several times with a delay in between:

panel:sendMidiMessageNow(CtrlrMidiMessage(“F0 7E 7F F7”))

–wait a bit
os.execute(sleep(20))

panel:sendMidiMessageNow(CtrlrMidiMessage(“F0 7E 7F F7”))

etc.

Don’t know if this helps…

• This reply was modified 6 years, 8 months ago by Possemo.

[EnzoF04]

Thanks, Possemo, but it does send complete messages. When I request a sample dump from the Atari, the sampler send a sysex message of 500+ bytes. When I send a request for sample dump by ctrlr panel, the sampler awnsers with inkt 20 bits message.

What gives you the idea that the sampler does not send a full message?

The delay / sleep function is a work around I have to test.
Thanks!

[Possemo]

Your documentation snippet tells this. It won’t send complete sysex messages, instead you have to aknowledge an uncomplete sysex message. I searched for the sysex implementation of the S700 to no avail but I found this in a forum:

I wish to write a sample editor/librarian for an S700 sampler that has an unusual sysex implementation. A sample dump would follow this procedure:

1. Computer sends dump request – 6 bytes including F0 and F7

2. Sampler replies with some sample parameters – 19 bytes including F0 but no F7

3. PC replies with acknowledge handshake – 4 bytes including F0 and F7

4. Sampler sends a block of data – 122 bytes with no F0 or F7

5. PC replies with acknowledge handshake – 4 bytes including F0 and F7

6. Sampler sends another block of data – 122 bytes with no F0 or F7

7. etc. – sample blocks and acks going back and forth

8. Sampler sends final block with an F7 as the final byte

Using the MaxMIDI DLLs is this kind of abnormal transaction permitted?
Even if it is, will Windows 95 complain?

Thanks,
Paul.

So I can’t be completely wrong, can I?

• This reply was modified 6 years, 8 months ago by Possemo.

[EnzoF04]

Well, exactly, Possemo. Consider it an incomplete message as such, as I consider it as complete with ack messages inbetween. Your approach gives me new perspectives. But still, I need to send an ack from the panel to the sampler within a certain timeframe wafer the fists 19 bytes are received. The sysex message will be completed with the EOX gyre.

Nice find about this post from a forum. Where did you get this? Thanks a lot!

[Possemo]

I found it here, a discussion from 1997:
https://forums.manning.com/posts/list/5148.page

If Ctrlr won’t do anything before F7 is received you will have to send lots of ACK messages blindly. If os.execute(sleep(20)) does not work you will have to use timers.

[EnzoF04]

That would be worth a good test! But more efficiently; if I somehow manage to count the incoming sysex bytes and when an amount is reached, I can send the ACK. It all is predictable when the sampler expects a ACK.

So is there a way of counting incoming bytes per message?
I haven’t searched yet…

Great input, Possemo, thanks!

[Possemo]

Well, what I’m trying to say is that I don’t know how Ctrlr behaves when a Sysex message is not terminated. I would first try to sort this out. So I would try this:

It seems you already made a button for e.g. requesting the first sample. So put something like this in the midiMessageReceived-script:

midiMessageReceived = function(midiMessage)

 local messageSize = midiMessage:getData():getSize()

 -- if size is 19 then we get the first message, the sample params. The sequential number "sampleDumpMsgNr" is reset to 1

 if messageSize == 19 then

   sampleParams = midiMessage
   sampleDumpMsgNr = 1
   panel:sendMidiMessageNow(CtrlrMidiMessage("F0 7E 7F F7"))

 -- if size is 60 it is one of the sampleDump messages. We put them in variables with a sequential number: sampleDumpNr1, sampleDumpNr2, sampleDumpNr3... etc.

 elseif messageSize == 60 then

   _G["sampleDumpNr"..sampleDumpMsgNr]=midiMessage
   sampleDumpMsgNr = sampleDumpMsgNr+1

   -- display what we got. If it displays nothing in the console it means that this procedure does not work.
   console(string.format("%.2x", _G["sampleDumpNr"..sampleDumpMsgNr]))

   panel:sendMidiMessageNow(CtrlrMidiMessage("F0 7E 7F F7"))

 -- The last message is just an F7. Now we can assemble all the messages into a variable called "completeSampleDump"
 elseif messageSize == 1 and midiMessage:getData():getByte(0) == 0xF7 then

  -- put all parts together. Add as much "sampleDumpNrX" as needed. You could do that with a loop
  completeSampleDump=sampleParams..sampleDumpNr1..sampleDumpNr2..sampleDumpNr3.."F7"

 end
end

I haven’t tested it, there could be syntax errors. In this case Ctrlr would throw an error. Maybe other people like Goodweather would do it in a smarter way…

If it does not work (nothing displayed in the console) it means that Ctrlr won’t output an unfinished Sysex message and you will have to try sending ACK’s blindly.

• This reply was modified 6 years, 8 months ago by Possemo.

[EnzoF04]

Thanks Possemo! I will work on this tonight. What I’ve been doing is sending ACK’s when the messageSize is 18, 17 or 19. No satisfying results up til now. I thought that the messageSize is evaluated after the message was received not while it is coming in.

[Possemo]

True, message size and everything else will probably wait until the message is completed by an F7. Therefore this probably won’t work. You will know it for sure when you test it. I never dealt with a synth which does not follow this basic guideline.

[EnzoF04]

I just lost all data in my CTRLR project. I had some working code but now i have to redo all things I discovered.
I was messing with timers but couldn’t get it to work, ctrlr quitted unexpected.

I’ll start all over again soon.

[EnzoF04]

OK i’ve got an other panel with the timer working. It’s not clean code but it works for now. I have to continue and build the sysex communication in it. See attached.

My biggest question now is:
Is there a way to count the incoming sysex bytes in a sysex message? Like real time? Not the amount being told after the sysex message is received but while incoming?

Attachments:

You must be logged in to view attached files.

[Possemo]

So you tried my midireceived script? According to the old thread I did messageSize == 60 wrong – should be messageSize == 122.

No I don’t think that you can count messages other than with midiMessage:getSize().

I looked into your panel. Here the corrections I would do:

this script needs the “MidiMessage” variable in the function() brackets:

midiMessageReceived = function(MidiMessage)
	s = MidiMessage:getSize()
	console (tostring(s))
end

timer:startTimer(1, .5)
here you set that the timer is executed every 0.5 ms! This is way too fast. If you didn’t set a limit of 1000 cycles it would probably hang Ctrlr. The S700 won’t be happy either being battered with ACK messages. I would set it to 300 ms.

Sending the ACK’s blindly really could work. Try these corrections and it could be that MidiMessage contains the complete sampledump.

• This reply was modified 6 years, 8 months ago by Possemo.
• This reply was modified 6 years, 8 months ago by Possemo.

[human fly]

(soz just reading out of interest)
why would Ctrlr need to terminate the operation because an F7
has been sent? couldn’t sample data ‘packets’ be auto-numbered
and saved, until a message ending with F7 is received?
how does the Atari do it? doesn’t it count incoming bytes, then
check size, before sending an ‘ack’? the s700 will send slowly,
and Ctrlr will zummm back the 4 bytes much faster.

if you auto-‘ack’ at timed intervals, it will possibly cut short
that data block and skip to the next, and then you’ll have
incomplete chunks and probably unreadable or choppy data.
(just my instinctive response; i hadn’t conceived of loading
sample data into Ctrlr – seems pretty hardcore 🙂 i’m just
trying to picture which is the S700.. not the S750, or 612.
would be a good way of managing samples using a PC, i guess?)

[Possemo]

Why waiting for F7? Read the answers to this question: https://forums.manning.com/posts/list/5148.page

I don’t see why sending ACK’s blindly should’t work. The S700 will just send its blocks in sequential order. Why should it omit one block? After all this is a stupid method of checking integrity of the data. A simple checksum would have been much more reliable. So you don’t lose too much when you doing it blindly. When it receives a complete dump including F7 it should be ok in 99% of cases.

• This reply was modified 6 years, 8 months ago by Possemo.
• This reply was modified 6 years, 8 months ago by Possemo.
• This reply was modified 6 years, 8 months ago by Possemo.

[EnzoF04]

Success! By just randomly sending of Ack messages I get a bigger sysex message. The max bytes I get in the sysex message is 752.

When I get the same sample from the sampler with the Atari I see the same 752 bytes passing! This is really great! No I can build the code for cleaning the received bytes into understandable / interpretable data. This is a giant leap for S700-kind… 😉
@Human Fly: It would really be nice to store the samples via Midi into a CTRLR panel because almost all the QuickDisk-drives are dead in those samplers.

@Possemo: The timer is now on 15. When it is slower i don’t get the whole message. I stop the timer after 250.

[Author]

Posts