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.

Is there anything in iOS which can generate Sysex-es and also receive them ?

Again me with dumb question :-)) I need some app which sends (generates) some Sysex data (to selected virual MIDI port) and also RECEIVES those data (from selecged virual port) and does actually something based on that data ..

I need to test recording and sending syses in app in wich i am working an don't have currently any HW at my hands ...

Comments

  • Streambyter and Mozaic

  • Be aware that Streambyter cannot send SysEx longer than 16 bytes; no problem receiving though.

  • @Richtowns has made a nice Mozaic patch that uses sysex:
    https://patchstorage.com/launch-control-xl-leds/

  • @uncledave said:
    Be aware that Streambyter cannot send SysEx longer than 16 bytes; no problem receiving though.

    There is a workaround for that by using a flag to suppress midi validation. There is a mention about it in the manual and I found this discussion:

    https://audeonic.boards.net/thread/1010/assistance-sending-long-sysex-messages

    I had to make use of that some years ago…though I ended up switching to mozaic because it was simpler for my use.

  • @espiegel123 said:

    @uncledave said:
    Be aware that Streambyter cannot send SysEx longer than 16 bytes; no problem receiving though.

    There is a workaround for that by using a flag to suppress midi validation. There is a mention about it in the manual and I found this discussion:

    https://audeonic.boards.net/thread/1010/assistance-sending-long-sysex-messages

    I had to make use of that some years ago…though I ended up switching to mozaic because it was simpler for my use.

    I don't believe that's enough. The message fragments are sent separately, so the receiving app does not see the complete message. It might work going to hardware, but not app-to-app. Anyway, not what the OP wants to be involved with.

  • wimwim
    edited April 9

    Loopy Pro can send sysex from widgets. You can even do substitution of the value (0x00 - 0x7F) of a slider or knob in the sysex string. I don't think Loopy can react to sysex though (?).

    Most sysex communication is way more complicated than just sending a few messages though. There are hardware identifiers, handshakes, sometimes CRCs ...

    As I was typing this, KQ Dixie came to mind. I think it can send and receive sysex just like a hardware DX7. That might be a very good app to try working with. Since the protocol is surely available online somewhere, it seems like a good choice.

  • edited April 10

    @wim said:
    As I was typing this, KQ Dixie came to mind. I think it can send and receive sysex just like a hardware DX7. That might be a very good app to try working with. Since the protocol is surely available online somewhere, it seems like a good choice.

    That is exactly what i am looking for ! All those Mozaic/Steambyter stuff - i am using all my brain capacity for this app so i need something simple straigtforward :)) Simple synth which sends/receives patch sysexes, that's it, that's probably main use case for the kind of app i am working on ! I knew you will come with good answer, if my playing with this app developement ever gets to stage where i decide i really want to release it, expect my private message regarding beta testing :smiley:

  • @wim said:
    Loopy Pro can send sysex from widgets. You can even do substitution of the value (0x00 - 0x7F) of a slider or knob in the sysex string. I don't think Loopy can react to sysex though (?).

    Most sysex communication is way more complicated than just sending a few messages though. There are hardware identifiers, handshakes, sometimes CRCs ...

    As I was typing this, KQ Dixie came to mind. I think it can send and receive sysex just like a hardware DX7. That might be a very good app to try working with. Since the protocol is surely available online somewhere, it seems like a good choice.

    any idea WHAT i should do in Dixie to force it to sen any sysex data ?? i contnect it to mfxMonitor (midi montior) but all i see are notes .. no sysexes whatever i do in dixie..

  • wimwim
    edited April 10

    @dendy said:

    @wim said:
    Loopy Pro can send sysex from widgets. You can even do substitution of the value (0x00 - 0x7F) of a slider or knob in the sysex string. I don't think Loopy can react to sysex though (?).

    Most sysex communication is way more complicated than just sending a few messages though. There are hardware identifiers, handshakes, sometimes CRCs ...

    As I was typing this, KQ Dixie came to mind. I think it can send and receive sysex just like a hardware DX7. That might be a very good app to try working with. Since the protocol is surely available online somewhere, it seems like a good choice.

    any idea WHAT i should do in Dixie to force it to sen any sysex data ?? i contnect it to mfxMonitor (midi montior) but all i see are notes .. no sysexes whatever i do in dixie..

    Nope. I'm virtually sysex illiterate. I think I'm probably also wrong about two-way communication. Here's all I know:
    https://www.kiraqtech.jp/blog/kq-dixie-en/kq-dixie-faq/#sendpatch

    Sysex is a bitch to understand.

  • Sending and receiving sysex to/from Mozaic is almost trivial. Sending sysex that does anything, or works anything like what you run into with hardware is a far different matter.

  • ok.. they i'll rather just grab some HW and try it with HW ..

  • @dendy said:

    @wim said:
    Loopy Pro can send sysex from widgets. You can even do substitution of the value (0x00 - 0x7F) of a slider or knob in the sysex string. I don't think Loopy can react to sysex though (?).

    Most sysex communication is way more complicated than just sending a few messages though. There are hardware identifiers, handshakes, sometimes CRCs ...

    As I was typing this, KQ Dixie came to mind. I think it can send and receive sysex just like a hardware DX7. That might be a very good app to try working with. Since the protocol is surely available online somewhere, it seems like a good choice.

    any idea WHAT i should do in Dixie to force it to sen any sysex data ?? i contnect it to mfxMonitor (midi montior) but all i see are notes .. no sysexes whatever i do in dixie..

    My impression is that it only sends sysex when connected to a DX7 or something that emulates the dx7’s sysex protocol.

  • @espiegel123 said:

    @dendy said:

    @wim said:
    Loopy Pro can send sysex from widgets. You can even do substitution of the value (0x00 - 0x7F) of a slider or knob in the sysex string. I don't think Loopy can react to sysex though (?).

    Most sysex communication is way more complicated than just sending a few messages though. There are hardware identifiers, handshakes, sometimes CRCs ...

    As I was typing this, KQ Dixie came to mind. I think it can send and receive sysex just like a hardware DX7. That might be a very good app to try working with. Since the protocol is surely available online somewhere, it seems like a good choice.

    any idea WHAT i should do in Dixie to force it to sen any sysex data ?? i contnect it to mfxMonitor (midi montior) but all i see are notes .. no sysexes whatever i do in dixie..

    My impression is that it only sends sysex when connected to a DX7 or something that emulates the dx7’s sysex protocol.

    That's my impression too. I think it has to receive the Manufacturer ID and maybe some sort of handshake to get to talking.

    This is why I suggested it as a possible test subject for real-world sysex type of communication, which involves more than just throwing around a few F0 ... F7 wrapped byte streams.

  • @dendy said:
    ok.. they i'll rather just grab some HW and try it with HW ..

    You'll still need to understand the handshake protocol.

  • edited April 10

    @wim said:

    @dendy said:
    ok.. they i'll rather just grab some HW and try it with HW ..

    You'll still need to understand the handshake protocol.

    This is imporant for large packets - like sysex dumps of firmware, SDS and stuff like that .. i am thinking more like just about shorter sysexes .. thinks like sending specific parameters, or sending PATCH and stuff like that .. there handshaking makes no sense ..

    Like, think in DAW world .. you want to store sysex of some external HW synth in your clip so when clip plays it sets proper patch to external hw synth .. those are usually short messages .. so no handshake needed ..

    You don't send large SDS / firmware dumps from timeline / clip in DAW (until you are not completely insane lol) .. I never tried to do such insanity even in big desktop DAWs, i was always like "no, this makes no sense to send many kilobytes or even megabytes long sysexes from DAW timeline" :))

  • wimwim
    edited April 10

    @dendy said:

    @wim said:

    @dendy said:
    ok.. they i'll rather just grab some HW and try it with HW ..

    You'll still need to understand the handshake protocol.

    This is imporant for large packets - like sysex dumps of firmware, SDS and stuff like that .. i am thinking more like just about shorter sysexes .. thinks like sending specific parameters, or sending PATCH and stuff like that .. there handshaking makes no sense ..

    Like, think in DAW world .. you want to store sysex of some external HW synth in your clip so when clip plays it sets proper patch to external hw synth .. those are usually short messages .. so no handshake needed ..

    You don't send large SDS / firmware dumps from timeline / clip in DAW (until you are not completely insane lol) .. I never tried to do such insanity even in big desktop DAWs, i was always like "no, this makes no sense to send many kilobytes or even megabytes long sysexes from DAW timeline" :))

    I'm pretty sure an initial handshake is still needed. The Machine ID and probably whether or not CRCs are used are required, I believe. We have granular routing capabilities in things like AUM, but sysex is designed for communication where multiple devices can be on the same "wire" or "network" ... for lack of a better term.

    Sysex is a channel-less protocol, so there has to be something to identify which device the messages are meant for.

  • @dendy: keep in mind that when sending sysex or even just progra> @wim said:

    @dendy said:

    @wim said:

    @dendy said:
    ok.. they i'll rather just grab some HW and try it with HW ..

    You'll still need to understand the handshake protocol.

    This is imporant for large packets - like sysex dumps of firmware, SDS and stuff like that .. i am thinking more like just about shorter sysexes .. thinks like sending specific parameters, or sending PATCH and stuff like that .. there handshaking makes no sense ..

    Like, think in DAW world .. you want to store sysex of some external HW synth in your clip so when clip plays it sets proper patch to external hw synth .. those are usually short messages .. so no handshake needed ..

    You don't send large SDS / firmware dumps from timeline / clip in DAW (until you are not completely insane lol) .. I never tried to do such insanity even in big desktop DAWs, i was always like "no, this makes no sense to send many kilobytes or even megabytes long sysexes from DAW timeline" :))

    I'm pretty sure an initial handshake is still needed. The Machine ID and probably whether or not CRCs are used are required, I believe.

    Sysex is a channel-less protocol, so there has to be something to identify which device the messages are meant for.

    Often devices rely on "header" bytes at the beginning of the sysex message that contain a manufacturer id and model id that devices use to decide whether to accept the messages. In those cases there may not be an additional handshake.

  • @dendy Back when I was using hardware I used MIDI Toolbox SYSEX Librarian to load and save patches etc. from my iPad if that helps. It shows content of SYSEX files. 😎✌🏼

    https://apps.apple.com/us/app/midi-tool-box/id443115330

  • @dendy If you ever need a hell of a sysex device to test with, I have a Lexicon MPX1 here 😅

  • @espiegel123 said:
    @dendy: keep in mind that when sending sysex or even just progra> @wim said:

    @dendy said:

    @wim said:

    @dendy said:
    ok.. they i'll rather just grab some HW and try it with HW ..

    You'll still need to understand the handshake protocol.

    This is imporant for large packets - like sysex dumps of firmware, SDS and stuff like that .. i am thinking more like just about shorter sysexes .. thinks like sending specific parameters, or sending PATCH and stuff like that .. there handshaking makes no sense ..

    Like, think in DAW world .. you want to store sysex of some external HW synth in your clip so when clip plays it sets proper patch to external hw synth .. those are usually short messages .. so no handshake needed ..

    You don't send large SDS / firmware dumps from timeline / clip in DAW (until you are not completely insane lol) .. I never tried to do such insanity even in big desktop DAWs, i was always like "no, this makes no sense to send many kilobytes or even megabytes long sysexes from DAW timeline" :))

    I'm pretty sure an initial handshake is still needed. The Machine ID and probably whether or not CRCs are used are required, I believe.

    Sysex is a channel-less protocol, so there has to be something to identify which device the messages are meant for.

    Often devices rely on "header" bytes at the beginning of the sysex message that contain a manufacturer id and model id that devices use to decide whether to accept the messages. In those cases there may not be an additional handshake.

    Yeah. That’s what I meat but I used the term “handshake” too freely. Thanks for that important clarification.

  • @dendy : FWIW, if you have a launchpad or launch key, they have pretty straightforward sysex and the documentation is pretty good.

Sign In or Register to comment.