samoht

Forum Replies Created

Viewing 20 posts - 1 through 20 (of 54 total)
  • Author
    Posts
  • in reply to: how to send program change with LUA #121250
    samoht
    Participant
      • Topics: 1
      • Replies: 54
      • Total: 55

      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.

      • This reply was modified 3 years, 3 months ago by samoht.
      • This reply was modified 3 years, 3 months ago by samoht.
      in reply to: how to send program change with LUA #121249
      samoht
      Participant
        • Topics: 1
        • Replies: 54
        • Total: 55

        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.

        • This reply was modified 3 years, 3 months ago by samoht.
        • This reply was modified 3 years, 3 months ago by samoht.
        in reply to: Ctrlr can’t be reached sometimes and somewhere #120936
        samoht
        Participant
          • Topics: 1
          • Replies: 54
          • Total: 55

          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.
          in reply to: Ctrlr can’t be reached sometimes and somewhere #120560
          samoht
          Participant
            • Topics: 1
            • Replies: 54
            • Total: 55

            November 2 was the only day this week I could reach ctrlr.org from home.

            in reply to: Ctrlr can’t be reached sometimes and somewhere #120508
            samoht
            Participant
              • Topics: 1
              • Replies: 54
              • Total: 55

              Today I can reach ctrlr.org again at home 🙂

              in reply to: Ctrlr can’t be reached sometimes and somewhere #120486
              samoht
              Participant
                • Topics: 1
                • Replies: 54
                • Total: 55

                @dasfaker

                Thanks!

                in reply to: Ctrlr can’t be reached sometimes and somewhere #120481
                samoht
                Participant
                  • Topics: 1
                  • Replies: 54
                  • Total: 55

                  Hi all,

                  The problem still persists…

                  in reply to: Build Ctrlr on Windows 10 and others #119955
                  samoht
                  Participant
                    • Topics: 1
                    • Replies: 54
                    • Total: 55

                    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,

                    in reply to: Looking for the basic sysex receive/send panel #119820
                    samoht
                    Participant
                      • Topics: 1
                      • Replies: 54
                      • Total: 55

                      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.
                      in reply to: Looking for the basic sysex receive/send panel #119813
                      samoht
                      Participant
                        • Topics: 1
                        • Replies: 54
                        • Total: 55

                        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.
                        in reply to: getSize only looking at last byte number #119732
                        samoht
                        Participant
                          • Topics: 1
                          • Replies: 54
                          • Total: 55

                          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.

                          • This reply was modified 3 years, 6 months ago by samoht.
                          • This reply was modified 3 years, 6 months ago by samoht.
                          in reply to: getSize only looking at last byte number #119729
                          samoht
                          Participant
                            • Topics: 1
                            • Replies: 54
                            • Total: 55

                            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.”

                            • This reply was modified 3 years, 6 months ago by samoht.
                            • This reply was modified 3 years, 6 months ago by samoht.
                            in reply to: getSize only looking at last byte number #119725
                            samoht
                            Participant
                              • Topics: 1
                              • Replies: 54
                              • Total: 55

                              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

                              in reply to: getSize only looking at last byte number #119724
                              samoht
                              Participant
                                • Topics: 1
                                • Replies: 54
                                • Total: 55

                                Hi goodweather,

                                file:///media/fuse/drivefs-ba7299c55cd588fe9c050512a5947586/root/AkaiS700_MIDI_Implementation_V1.0.pdf

                                Regards,
                                Thomas

                                in reply to: getSize only looking at last byte number #119715
                                samoht
                                Participant
                                  • Topics: 1
                                  • Replies: 54
                                  • Total: 55

                                  I’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.
                                  in reply to: getSize only looking at last byte number #119710
                                  samoht
                                  Participant
                                    • Topics: 1
                                    • Replies: 54
                                    • Total: 55

                                    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.
                                    in reply to: getSize only looking at last byte number #119708
                                    samoht
                                    Participant
                                      • Topics: 1
                                      • Replies: 54
                                      • Total: 55

                                      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.
                                      in reply to: getSize only looking at last byte number #119703
                                      samoht
                                      Participant
                                        • Topics: 1
                                        • Replies: 54
                                        • Total: 55

                                        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

                                        in reply to: getSize only looking at last byte number #119701
                                        samoht
                                        Participant
                                          • Topics: 1
                                          • Replies: 54
                                          • Total: 55

                                          So, requesting data:

                                          RQD ---------->
                                          
                                              <----------DAT
                                          
                                          ACK ---------->
                                          
                                              <----------DAT
                                          
                                          ACK ----------->
                                                   -
                                                   -
                                              <----------EOD
                                          
                                          ACK ----------->

                                          Sending data:

                                          WSD ---------->
                                          
                                              <----------ACK
                                          
                                          DAT ---------->
                                          
                                              <----------ACK
                                          
                                          DAT ---------->
                                          
                                              <----------ACK
                                                    -
                                                    -
                                          EOD ----------->
                                          
                                              <-----------ACK
                                          • This reply was modified 3 years, 6 months ago by samoht.
                                          • This reply was modified 3 years, 6 months ago by samoht.
                                          in reply to: getSize only looking at last byte number #119700
                                          samoht
                                          Participant
                                            • Topics: 1
                                            • Replies: 54
                                            • Total: 55

                                            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

                                          Viewing 20 posts - 1 through 20 (of 54 total)
                                          Ctrlr