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.

PatternBud By Cem Olcay

124»

Comments

  • uncledaveuncledave
    edited September 2025

    For a really clean solution, you could let PatternBud send a CC, say CC70, and use Streambyter to convert the message to PC. The rule would be

    BX 46 XX = CX X3

    BX 46 recognizes CC70 on any channel (remember to convert the CC# to hex); CX converts it to PC on the same channel. X3 uses the third byte of the CC message (the value) as the PC number.

  • cem_olcaycem_olcay

    @uncledave said:
    I suspect the problem here is that PC is a 2-byte message, but PatternBud always sends 3 bytes. In the monitors, "192" is actually hex C0, PC on channel 0. It's followed by the program number, then the extraneous extra zero. I'm not sure how apps handle mal-formatted MIDI. StreamByter may be "fixing" it by silently dropping the extra byte, regardless of the filter.

    Edit: I notice in Cem's post up-thread the monitor shows a 3rd byte of 0xFF, which he does not remark on. And in this recent post, the extra byte is sometimes "112", which is 0x70, but the monitor shows it as Channel 16, not sure how that makes sense. I suspect that the value of the extra byte sent by PatternBud is just something left lying around in memory.

    That was the correct insight! Standalone version was sending the PC message in correct format but AUv3 version was sending in 3-byte (corrupted) form. I fixed the issue and uploaded a new version. It will be live soon!

  • cem_olcaycem_olcay

    @cem_olcay said:

    @uncledave said:
    I suspect the problem here is that PC is a 2-byte message, but PatternBud always sends 3 bytes. In the monitors, "192" is actually hex C0, PC on channel 0. It's followed by the program number, then the extraneous extra zero. I'm not sure how apps handle mal-formatted MIDI. StreamByter may be "fixing" it by silently dropping the extra byte, regardless of the filter.

    Edit: I notice in Cem's post up-thread the monitor shows a 3rd byte of 0xFF, which he does not remark on. And in this recent post, the extra byte is sometimes "112", which is 0x70, but the monitor shows it as Channel 16, not sure how that makes sense. I suspect that the value of the extra byte sent by PatternBud is just something left lying around in memory.

    That was the correct insight! Standalone version was sending the PC message in correct format but AUv3 version was sending in 3-byte (corrupted) form. I fixed the issue and uploaded a new version. It will be live soon!

    The new version is live!

  • bobbydozenbobbydozen

    New member here, so forgive me if I'm asking a stupid question... I basically wanted to use this as a better way of doing MIDI automation than is currently available in Loopy Pro (no viewing or editing of MIDI data, as far as I can tell).

    If say, I wanted a volume automation, I could concievably program this within Patternbud sending out a CC that's mapped to the right parameter in Loopy, right? But then I don't know how I'd trigger that stream of CC data at the right moment within the Loopy timeline... Perhaps I'm looking at this the wrong way?

Sign In or Register to comment.