Loopy Pro: Create music, your way.

What is Loopy Pro? — Loopy Pro is a powerful, flexible, and intuitive live looper, sampler, clip launcher and DAW for iPhone and iPad. At its core, it allows you to record and layer sounds in real-time to create complex musical arrangements. But it doesn’t stop there—Loopy Pro offers advanced tools to customize your workflow, build dynamic performance setups, and create a seamless connection between instruments, effects, and external gear.

Use it for live looping, sequencing, arranging, mixing, and much more. Whether you're a live performer, a producer, or just experimenting with sound, Loopy Pro helps you take control of your creative process.

Download on the App Store

Loopy Pro is your all-in-one musical toolkit. Try it for free today.

Mozaic: How to send sysex numbers that are >255?

josh83josh83
in App Tips and Tricks

I just noticed that I can't send numbers >255 using sysex:

@OnLoad
  data = [254, 255, 256, 257]
  SendSysex data, 4
@End

@OnSysex
  ReceiveSysex data
  Log data[0]
  Log data[1]
  Log data[2]
  Log data[3]
@End

Output:

254
255
0
1

It seems to "wrap around" and start at 0 when reaching 256.

Is this really the limit? Can't I send anything bigger than 256?

Thank you.

«1

Comments

  • 0tolerance4silence0tolerance4silence

    AFAIK that’s midi standard limit. No app or hardware could handle values above. I could be wrong...

  • [Deleted User][Deleted User]
    The user and all related content has been deleted.
  • josh83josh83

    Okay, thank you.

  • noobnoob

    Midi for nw s 8bit since the 80s

  • josh83josh83

    Is there any way to work around this limit? AFAIK Sysex can transmit any kind of data somehow...?

  • rs2000rs2000

    @josh83 Parameters with higher resolution are usually split into multiple "packets".
    Manufacturers are free to define whatever weirdness they desire.
    There have been a few attempts to have some kind of common sense in the past decades but without much success.

  • josh83josh83

    @rs2000 said:
    @josh83 Parameters with higher resolution are usually split into multiple "packets".
    Manufacturers are free to define whatever weirdness they desire.
    There have been a few attempts to have some kind of common sense in the past decades but without much success.

    Hm, using Mozaic, does anyone know a good solution/workaround/hack?

  • rs2000rs2000

    @josh83 said:

    @rs2000 said:
    @josh83 Parameters with higher resolution are usually split into multiple "packets".
    Manufacturers are free to define whatever weirdness they desire.
    There have been a few attempts to have some kind of common sense in the past decades but without much success.

    Hm, using Mozaic, does anyone know a good solution/workaround/hack?

    Yes, use sysex the way it's designed.

  • wimwim

    Pitch bend combines two bytes (MSB * LSB), for 16,384 values with max of 127 for each byte. Perhaps you could do the same with your sysex messages.

  • josh83josh83

    Hm sounds frightening. ;-) I will see whether I find another way to reach my goal.

    Thanks anyway, guys!

  • espiegel123espiegel123

    @josh83 said:
    Is there any way to work around this limit? AFAIK Sysex can transmit any kind of data somehow...?

    It depends on the device that is receiving it. You need to find out what it’s protocols and proceed accordingly. Are you sure your device handles values over 255? Some MIDI, btw, isn’t 8-bit...and uses only 7-bits. There are some calculators to be found on the web to convert values over 127 into multiple 7-bit bytes.

  • rs2000rs2000

    @josh83 said:
    Hm sounds frightening. ;-) I will see whether I find another way to reach my goal.

    Thanks anyway, guys!

    Goal? What goal? 🤔

  • josh83josh83

    I'm desperately trying to create a rather complex script using Mozaic. ;-) Nevermind, I will find my way. One day I will have hit all the limitations of MIDI and Mozaic, and then I will know how to reach my goal... :smiley:

  • xorxor

    Not sure if this is what you’re looking for but you can always decompose a large integer into a sequence of bytes and recombine them into the original integer... note: this only works for integers

    // Split a large number into separate bytes
data[0] = largerValue % 256; 
data[1] = div(largerValue, 256);

// Combine multiple bytes into a larger number
largerValue = data[1] * 256 + data[0]
  • josh83josh83

    Thanks, @xor. Does this work for any big integer number? E.g. would it work for 1234 and 12345678 in the same procedure? (Sorry, I'm too lazy to try to understand your code). :wink:

  • _ki_ki
    edited November 2020

    Yes - midi sysex sends out a given number of bytes, each is 8 bit. Therefore the value range of each data element is 0 to 255.

    To send larger values, you need to split them into several bytes on the sender and recombine the values at the receiver. With two bytes you could send values from 0 to 65535:

    l_byte = value & 0xff
h_byte = Div value, 256

....

value = h_byte * 256 + l_byte

    There are other common conversions to byte for larger unsigned integer ranges, fixed point values or even floats.

  • [Deleted User][Deleted User]
    The user and all related content has been deleted.
  • espiegel123espiegel123

    @_ki said:
    Yes - midi sysex sends out a given number of bytes, each is 8 bit. Therefore the value range of each data element is 0 to 255.

    To send larger values, you need to split them into several bytes on the sender and recombine the values at the receiver. With two bytes you could send values from 0 to 65535:

    l_byte = value & 0xff
h_byte = Div value, 256

....

value = h_byte * 256 + l_byte

    There are other common conversions to byte for larger unsigned integer ranges, fixed point values or even floats.

    And you need to know what the device supports. I have a Roland device and even in sysex streams it uses 7-bit bytes not 8-bit bytes. This is because the “end of sysex” message is an 8-bit value. So, if you could have 8-bit values in the sysex stream, you might end up having that value mid-stream. I could be wrong but I think most devices use 7-bit values for sysex bytes.

  • espiegel123espiegel123

    @tja said:

    @espiegel123 said:

    @josh83 said:
    Is there any way to work around this limit? AFAIK Sysex can transmit any kind of data somehow...?

    It depends on the device that is receiving it. You need to find out what it’s protocols and proceed accordingly. Are you sure your device handles values over 255? Some MIDI, btw, isn’t 8-bit...and uses only 7-bits. There are some calculators to be found on the web to convert values over 127 into multiple 7-bit bytes.

    This is not true.

    MIDI uses bytes of 8 bits and therefore can and will use values of 0 to 255.

    You may refer to different usages of MIDI messages, which are distinguished by the highest bit.

    Here more detail:

    https://ccrma.stanford.edu/~craig/articles/linuxmidi/misc/essenmidi.html

    Sysex is weird because (as noted above) the “end of packet” message is an 8-bit byte.

    I only know about this because I had to reverse engineer some sysex stuff where I needed to send values over 127 (in my case up to 999) and things didn’t work until a kind person pointed out to me that most devices use 7-bit bytes inside of sysex streams.

    There is even a site (maybe a page on the MIDI Designer Pro site) that converts numbers into the correct sequence of 7-bit bytes.

    There are many articles to be found about this on the web.

    This discussion may be of interest:
    https://forum.juce.com/t/sysex-messages-containing-bytes-greater-than-127/34792/3

  • wimwim

    There's no reason to assume we're talking about hardware here. @josh83 may be using Sysex in other ways, such as communication between different scripts. For that one could well need to send values over 255. The bottom line however is bytes will need to be combined to get those values.

  • espiegel123espiegel123
    edited November 2020

    @wim said:
    There's no reason to assume we're talking about hardware here. @josh83 may be using Sysex in other ways, such as communication between different scripts. For that one could well need to send values over 255. The bottom line however is bytes will need to be combined to get those values.

    if the receiver relies on the “end of sysex” value, it can’t contain that value in the stream. It would possible to ignore that if a receiver uses a byte count at the beginning of the sysex message and doesn’t terminate the stream when it sees the “end of sysex” byte.

    As I said, you need to know that the device (or receiver) uses as its protocol. If you used Mozaic as receiver, for instance, your received sysex message would be truncated if it contained the “end of sysex” byte value.

    In any case, as I said earlier, you need to know what the receiver expects.

  • xorxor
    edited November 2020

    @josh83 since each byte can hold a number up to (but not including) 256, 2 bytes can hold up to 256 * 256 or 65536. Three bytes can hold 256 * 256 * 256 or 16,777,216. So you have to figure out the largest number you want to support and choose the number of bytes accordingly. A general formula for N bytes is:

    value = 100000
for n = 0 to 2
   data[n] = ( Div value, ( Pow 256, n ) ) % 256
   log n, { }, data[n]
endfor 

value = 0
for n = 0 to 2
  value = value + ( data[n] * ( Pow 256, n ) )
endfor
  • espiegel123espiegel123

    @tja: btw, if you read the document you linked to, you will see that pitch-bend uses two 7-bit bytes for its values. One for the high order part of the value one for the lower order part. The part of the article talking about 8-bit values is just an overview about bytes and the possible values a byte can have. It doesn’t mean that all MIDI values use 8-bit values.

    (Btw, 7-bit bytes are 8 bits long. It is just that the first bit is ignored).

  • espiegel123espiegel123

    @xor said:
    @josh83 since each byte can hold a number up to (but not including) 256, 2 bytes can hold up to 256 * 256 or 65536. Three bytes can hold 256 * 256 * 256 or 16,777,216. So you have to figure out the largest number you want to support and choose the number of bytes accordingly. A general formula for N bytes is:

    value = 100000
for n = 0 to 2
   data[n] = ( Div value, ( Pow 256, n ) ) % 256
   log n, { }, data[n]
endfor 
  
value = 0
for n = 0 to 2
  value = value + ( data[n] * ( Pow 256, n ) )
endfor

    Btw, you can only do that if the receiver doesn’t treat 247 as the “end of sysex” marker. (You could also choose not to allow 247 as a value to get around this).

  • [Deleted User][Deleted User]
    The user and all related content has been deleted.
  • espiegel123espiegel123

    @tja said:

    @espiegel123 said:

    @tja said:

    @espiegel123 said:

    @josh83 said:
    Is there any way to work around this limit? AFAIK Sysex can transmit any kind of data somehow...?

    It depends on the device that is receiving it. You need to find out what it’s protocols and proceed accordingly. Are you sure your device handles values over 255? Some MIDI, btw, isn’t 8-bit...and uses only 7-bits. There are some calculators to be found on the web to convert values over 127 into multiple 7-bit bytes.

    This is not true.

    MIDI uses bytes of 8 bits and therefore can and will use values of 0 to 255.

    You may refer to different usages of MIDI messages, which are distinguished by the highest bit.

    Here more detail:

    https://ccrma.stanford.edu/~craig/articles/linuxmidi/misc/essenmidi.html

    Sysex is weird because (as noted above) the “end of packet” message is an 8-bit byte.

    I only know about this because I had to reverse engineer some sysex stuff where I needed to send values over 127 (in my case up to 999) and things didn’t work until a kind person pointed out to me that most devices use 7-bit bytes inside of sysex streams.

    There is even a site (maybe a page on the MIDI Designer Pro site) that converts numbers into the correct sequence of 7-bit bytes.

    There are many articles to be found about this on the web.

    This discussion may be of interest:
    https://forum.juce.com/t/sysex-messages-containing-bytes-greater-than-127/34792/3

    Those are still sequences of bytes, each 8 bit.

    As i wrote, we talk about the usage type, possibly indicated by the highest bit.

    This may help:

    http://midi.teragonaudio.com/tech/midispec/sysex.htm

    Even if only 7 bits are of interest to an App, the MIDI stream consists of regular bytes of 8 bits each.

    And, as @wim wrote, of course you can also interprete 2 bytes as a 16-bit number or 4 bytes as 32 bit number, as usual with computers. But does not change, that MIDI consists of sequences of bytes.

    The website you mentioned referes to http://www.somascape.org/midi/tech/spec.html#sysexmsgs

    And it says the same!

    The sysex messages are just bytes that have the top-bit set to zero, so take values between 0 and 127, still in 8 bit.

    I think you misunderstood what I wrote. What programmers call “7-bit bytes” are normal 8-bit bytes except that the first bit is ignored. For most sysex applications, this is important because values over 127 need two “7-bit bytes”.

  • espiegel123espiegel123

    Also relevant. The 7-bit byte calculator I mentioned

    https://mididesigner.com/help/midi-byte-calculator/

  • rs2000rs2000

    @josh83 said:
    I'm desperately trying to create a rather complex script using Mozaic. ;-) Nevermind, I will find my way. One day I will have hit all the limitations of MIDI and Mozaic, and then I will know how to reach my goal... :smiley:

    Sounds like you're trying to control a Lexicon MPX1, a.k.a. the sysex devil 😅

  • 0tolerance4silence0tolerance4silence

    @rs2000 said:

    @josh83 said:
    I'm desperately trying to create a rather complex script using Mozaic. ;-) Nevermind, I will find my way. One day I will have hit all the limitations of MIDI and Mozaic, and then I will know how to reach my goal... :smiley:

    Sounds like you're trying to control a Lexicon MPX1, a.k.a. the sysex devil 😅

    Hehe... loved the sound, tried to make a controller, gave up, loved to see it go...

  • [Deleted User][Deleted User]
    The user and all related content has been deleted.
Sign In or Register to comment.

© Vanilla Keystone Theme 2024