Forum Replies Created
-
AuthorPosts
-
the function written in Lua only sends the first 3 bytes, does anyone know why and can help me?
I guess because your synth is reading the first byte 0xB8 and recognizes a control change message. Your synths brain is made to think that a control change message consists of 3 bytes, the first byte containing the identification of the message with channel, the second containing the cc number, the thirth a value. So the brain of your synth is made to be not aware of the following bytes in order not to confuse the message, already complete.
Hi all,
Not sure what you are intending to do.
0xB initiates a control change message, so I guess 0xB8= control change on channel 8 followed by 2 data bytes (one with a controller number and one with a value);
So the first 6 bytes of your message seem to represent 2 control change messages each of 3 bytes.0xC initiates a program change message, so I guess your seventh byte 0xC8 is a program change on channel 8 followed by one data byte 0x05 containing the program number.
These three messages are not of the sysex type (initiated by 0xF0 and ending with 0xF7).
I don’t think you need lua to send these control change and program change messages in Ctrlr, but others on this forum are more experienced about the subtlities of this types of messages in ctrlr.
Yesterday and today is was possible again to reach the ctrlr forum from home (for the first time since the second of November).
- This reply was modified 3 years, 3 months ago by samoht.
November 2 was the only day this week I could reach ctrlr.org from home.
Today I can reach ctrlr.org again at home 🙂
Hi all,
The problem still persists…
Hi goodwheater,
About ctrlr.jucer:
A .jucer file contains all the settings of a project started in Juce, so in this case all the settings of the ctrlr project in Juce. For more info see the following link with as prefix https:
//juce.com/discover/stories/projucer-manual.I follow your project with great interest.
Cheers,
Hi John,
It’s the U-220. Every chunk of the patch dump this unit sends out has the right header and checksum to send it back.
I fully understand your view on simplicity and I will thankfully use your code as a template to integrate into the U-220 panel I started.Cheers,
Thomas- This reply was modified 3 years, 6 months ago by samoht.
Hi dnaldoog,
Congratulations for this panel!
A good idea and nice code, not only to use but also to study, thanks to your willingness to share your code with us!
I’ve tried out the dump request mode on an old Roland synth.
This synth dumps his 64 ‘patches’ in eighty chunks, each with a header (8 bytes), a checksum and EOX (2 bytes) and 128 data bytes in between (so a total of 80×138 = 11040 bytes, but only 128×80 = 10240 data bytes)Using your panel, dump request and write to pc is working without any flaws on linux (dump = 11040 bytes).
Sending this ‘patches’ back to this Roland needs, at least for this synth, somewhat improvements, since every chunk has its own header with his own address and checksum.
So the panel could be further improved by providing a separate field (of course with associated lua code) where the number and length of the chunks could be entered, so they could each be sent separately.Cheers,
Thomas- This reply was modified 3 years, 6 months ago by samoht.
Hi all,
Some more additional info on SDS protocol that may be of interest:
When a sample transfer contains more than 128 data blocks (0-> 127), the number of the following block is set to 0 and so on like a three digit odometer jumping from 999 to 000.
This may help with identification of the data blocks.
Hi,
Some additional information:
In the midi implementation doc (very well set by Enzo) “closed loop transmission” is mentioned. What “handshaking procedure” is for Roland is “closed loop transmission” in the sample dump standard (SDS).
SDS is a standardized protocol. For more info on SDS see:http://www.4front-tech.com/pguide/midi/midi8.html
I want to draw attention to this sentence in the S700 doc: “A further enhancement of the standard sample dump protocol is that when closed loop transmission is used, gaps between blocks may be as long as 10 seconds rather than the 20mS specified.”
Hi goodweather,
Addendum:
For the complete manual with standard one page midi implementation chart at the end:https://www.polynominal.com/akai-s700/assets/files/akai-s700-manual.pdf
Thomas
Hi goodweather,
file:///media/fuse/drivefs-ba7299c55cd588fe9c050512a5947586/root/AkaiS700_MIDI_Implementation_V1.0.pdf
Regards,
ThomasI’ve found the Akai S700 midi implementation.
The handshaking procedure is not exactly, but fundamentally identic with the Roland procedure.
RSD -----> (request send data) <-----data (first of 546 blocks of data, all with 0x40 as 2nd byte, each with its own 1st byte) ACKS -----> (FO 7E 7F F7) <-----data (all 546 data blocks have the same length, I think 60 byte chunks) ACKS -----> <------EOX (F7)
- This reply was modified 3 years, 6 months ago by samoht.
I’ve not tried out what follows, it is a try to figure out a working procedure.
So, a data set can be identified when you know the position of 42H (Data set DAT) in every data set:
midiMessageReceived = function(midi) local idDAT = midi:getLuaData():getByte(5) -- dupposing byte 5 is 42H -->DAT if IdDAT == 0x42 then -- DAT Identification byte Dat = midi:getData()
What I don’t know is how you can differentiate between different chunks of data.
Therefore, after appending the already received DAT to a memory block outside midiMessageReceived as goodweather suggested, this already received block must disappear in the midi buffer. (In docs.juce.com/master/classMidiBuffer.html are methods to do this).Thereafter an ACK can be send and the second DAT can be recognized in the same manner.
So on until the remote machine sends an EOD.
This message can be recognized when you know the exact length of this message and/or the exact location of 45H in this message. A final ACK brings the communication to an end.All this steps can be done in one lua function
Cheers,
Thomas- This reply was modified 3 years, 6 months ago by samoht.
goodweather wrote:
in MidiMessageReceived, append message to memory block; check if message contains F7; if yes then call method to process the memory block; if not send ACK
A good procedure. but in my opinion you have to check not for F7 but for EOD (45H –>end of data) in a separate message. The communication stays open until the ACK is sent out responding to the EOD.
Sending arbitrary ACK messages may confuse the handshake procedure and disrupt communication.
- This reply was modified 3 years, 6 months ago by samoht.
So, after sending a RQD or WSD or EOD, you have to make some lua code to catch the ACK, ERR, DAT or RJC and to respond on each of them in an appropriate manner.
Thomas
So, requesting data:
RQD ----------> <----------DAT ACK ----------> <----------DAT ACK -----------> - - <----------EOD ACK ----------->
Sending data:
WSD ----------> <----------ACK DAT ----------> <----------ACK DAT ----------> <----------ACK - - EOD -----------> <-----------ACK
Hi all,
This way of exchanging data has a name: it is the handshake transfer procedure, also used by Roland in some older samplers and synths.
It was used for handling large amounts of data-sampler waveforms and synthesizer tones over the entire range as it was considered more efficient than one-way transfer.Types of messages:
-want to send data: WSD (40H)
-request data: RQD (41H)
-data set: DAT (42H)
-acknowledge: ACK (43H)
-end of data: EOD (45H)
-communication error: ERR (4EH)
-rejection: RJC (4FH)Concerning the ACK: this message is sent out when no error was detected on reception of a WSD, DAT, EOD. Unless it receives an ACK message, the device at the other end will not proceed to the next operation.
Concerning the EOD: this message is sent out to inform a remote device of the end of a message. Communication, however, will not come to an end unless the remote device returns an ACK message even though an EOD message was transmitted.
ERR warns the remote device of a communications fault encountered during message transmission due, for example, to a checksum error. An ERR message may be send out by a device on either side of the interface.
When it receives an ERR message, the sending device may either attempt to send out the last message a second time or terminate the communication by sending out an RJC.RJC is sent out when there is a need to terminate the communication. An RJC will be triggered when
-a WSD or RQD message has specified an illegal data address or size
-the device is not ready for communication
-an illegal number of adresses or data has been detected
-data transfer has been terminated by an operator
-a communications error has occurred -
AuthorPosts