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 - Create your own AU MIDI plugins - OUT NOW!

18081838586108

Comments

  • Has anyone written any scripts that send 14-bit midi?

  • @espiegel123 Yes, it is called bipolarSplitter. It converts pitchbend, up and down into two pairs of 14 bit cc's.

  • @Alfred said:
    @espiegel123 Yes, it is called bipolarSplitter. It converts pitchbend, up and down into two pairs of 14 bit cc's.

    Is that script yours? If so, I have a question. There is a place where if MIDIByte 3 > 64 it uses a different set of cc numbers. I was wondering if you could explain?

  • _ki_ki
    edited April 2021

    @espiegel123 Just from the context mentioned, i suspect that‘s where the ‚bipolar and splitting’ aspect of the script comes to play: A pitchbend down is send on one pair 14 bit CCs and the pitchbend up (ie MIDIByte3 > 64) is send to another CC pair - ie splitting both pitchbend directions.
    There is probably also some logic that ‚reset‘ the respective other CC pair to 8192 if the center is crossed - otherwise the other CC pair would stop at that last value send before the crossing happened

  • _ki_ki
    edited April 2021

    I just checked that script and my assumption was correct - the code line mentioned is responsible for the splitting of up-wards and down-wards pitchbend.

    The each CC pair will stay at the last pitchbend value send before the crossing - this can even be an advantage, e.g. if you move the PitchBend wheel quickly from top to bottom, the top value (used for instance for the filter) could stay on a higher value while then influencing the other modulation destination.

  • @_ki said:
    I just checked that script and my assumption was correct - the code line mentioned is responsible for the splitting of up-wards and down-wards pitchbend.

    The each CC pair will stay at the last pitchbend value send before the crossing - this can even be an advantage, e.g. if you move the PitchBend wheel quickly from top to bottom, the top value (used for instance for the filter) could stay on a higher value while then influencing the other modulation destination.

    Thanks.

    I am about to cobble something together to split values (0...16383) into MSB and LSB.

    Is this logic right?

    Let’s call the value to convert 14bitValue (And assume it is in range)

    To get the MSB

    temp = 14bitValue * 2 //shifts bits 1 left. Needed to get bit 8 into MSB
    MSB = (temp & 0x00FF00) / 0x100 //mask off LSB and shift right 8

    To get LSB
    LSB = (temp & 0x0000FF) / 2 //masks off MSB and shifts bits back to the right.

  • _ki_ki
    edited April 2021

    Hmm, on a first glance you conversion code seems fine. I but’ll check with some test examples in mozaic - the back conversion for sure is value = bytes2 + 128*byte3 and bytes are in range 0 to 127.

    ... a bit later:

    Your code works - but i think a shorter conversion is

      MSB = Div Value, 128  // Shift 7 bits right to move the upper 7 bits in position
      LSB = Value & 0x7F    // Mask out the lower 7 bits
    

    .

    .

    Here is the test code, i used to check if the conversions worked

    @OnLoad
      for i = 0 to 1000
        value = Random 0, 16383
        Call @ConvB    // or ConvA
        Call @TestConv
      endfor
      Log {---done---}
    @End
     
    @ConvA //param: Value out: MSB, LSB
      temp = Value * 2                // shifts bits 1 left. Needed to get bit 8 into MSB
      MSB  = (temp & 0x00FF00) / 0x100//mask off LSB and shift right 8
      LSB  = (temp & 0x0000FF) / 2    //masks off MSB and shifts bits back to the right.
    @End
     
    @ConvB //param: Value out: MSB, LSB
      MSB = Div Value, 128
      LSB = Value & 0x7F
    @End
     
    @TestConv // param Value, MSB, LSB
      check = LSB + 128*MSB
      if check <> Value or LSB<0 or LSB>127 or MSB<0 or MSB>127
        Log {Error: pVal=},pVal, {  pLSB=},pLSB, {  pMSB=},pMSB
      endif
    @End
    
  • edited April 2021

    Thanks @_ki for the review :-)
    When you use a wheel it physicaly automaticly resets to the center value.
    When using a touchstrip bender it might be possible to skip sending the center position.

    @espiegel123
    When I reviewed my code just now I noticed a mistake. You have to send the lsb first, because when you send the msb the receiver sets the total value of msb + lsb.

  • Still trying to grasp that bitshifting stuff allthough you guys did a great job explaining it before.
    For my own sanity I would use modulus.
    Lsb = value % 128

  • @Alfred said:
    Thanks @_ki for the review :-)
    When you use a wheel it physicaly automaticly resets to the center value.
    When using a touchstrip bender it might be possible to skip sending the center position.

    @espiegel123
    When I reviewed my code just now I noticed a mistake. You have to send the lsb first, because when you send the msb the receiver sets the total value of msb + lsb.

    Thanks! Btw: I was looking at the code in preparation to do the opposite -> turn Mozaic knob values into two 7-bit (MSB and LSB) values. And when that is working, I'd like to figure out a slewing method so that if one has a 7-bit midi knob (like on my Launchkey), it can do some smart slewing fill in values as you turn the dial up or down

  • I just searched PatchStorage but didn't find anything that does this: I want to define an input note (say C3) and then define a set number of specific notes that can play randomly. So, something like this:

    Play C3.
    25% chance C3 plays
    25% chance E3 plays
    25% chance G3 plays
    25% chance A3 plays

    The script would allow for between 2-7 different scenarios/percentages from 50/50 to ~15% for each note. Velocity, gate, etc remain the same as input.

  • Maybe you can use two 7 bit knobs like tune and finetune.
    Slewing by midi is not a good idea because of midi data overload.
    Synths dont like to be micromanaged like that.
    Have a look at my dataReducer script.

    For slewing you could maybe store the recieved lsb and msb in two arrays. And the play them back at a fixed rate.

    Most controllers can send cc and pitchbend at a very high rate when moved quickly.
    Most daws do data thining like in my script to protect against midi data overload.

  • @Alfred said:
    Maybe you can use two 7 bit knobs like tune and finetune.
    Slewing by midi is not a good idea because of midi data overload.
    Synths dont like to be micromanaged like that.
    Have a look at my dataReducer script.

    For slewing you could maybe store the recieved lsb and msb in two arrays. And the play them back at a fixed rate.

    Most controllers can send cc and pitchbend at a very high rate when moved quickly.
    Most daws do data thining like in my script to protect against midi data overload.

    I already have a two knobs (MSB plus LSB) solution. The reason I want to to implement a one knob solution is that two knobs makes the performance cumbersome. And I don't have at my disposal a set of 16 pitchbend wheels. So, I am hoping that I can come up with a scheme to do some smart interpolating/slewing to make a more performer-friendly control.

    The slewing script would use a controllable timer to let the user thin the stream so as not to overwhelm the receiving device and to allow customizing the ramping. With two knobs there is no way around zippering and a certain kind of jitter -- and from a performance standpoint it requires two hands in coordination to do something I am preferring to do with one hand.

    Is there something particular I would get out of your dataReducer script if I already have a script that thins a MIDI stream to a preferred data rate?

  • Ok I get what you want. Yeah maybe nothing, maybe another perspective you could get out of it. It contains the secret of the dropframe...

  • edited April 2021

    Any idea what could be crashing all my Mozaic plugs in Drambo (showing error) ? The project was working fine and I see no software change.
    Except 2 instances that are a little heavier, all scripts are just a few lines long (19 instances altogether).
    First time I see this. I have 1.3 GB of Inactive memory(RAM) and even 100 mb Free left.

  • @brambos
    Just a little question regarding cubasis.
    OnNewBar, is the HostBar value provided by the HOST ?
    The problem is that if I have a 4 bar loop, HostBar will show 0,1,2,3, 4,1,2,3, 4,1,2,3 ...
    Now if I start a 1 msec Timer in OnNewBar I will get the right HostBar 0,1,2,3, 0,1,2,3, 0,1,2,3 ...
    It's probably a Cubasis thingy but just wanted to make sure before my lawyers contact @Lars and co :)
    Thanks.

  • _ki_ki
    edited June 2021

    I just notices that i forgot to announce the release ofthe Multi Divisi script some time ago.

    Splits and clones midi into separate channels to maximise the usage of 3-10 output voices to achieve a fatter sound whenever possible.

    Single notes or chords will choose an pitch-ordered optimal initial distribution using all available voices. As long as one of the notes is sustained, adding or releasing notes will continously update the voice slots using complex optimization strategies. An intermediate release of all keys ends the current distribution run and the next note(s) will start with a new optimal initial configuration.

    The script suppports multi channel midi. Controllers and expressions are only routed to voices originating from the same channel. The pitchbend / aftertouch / slide (CC-74) / modwheel (CC-1) / expression (CC-11) are tracked per channel and updated on channel changes before a new note on. In MPE mode, controllers and expressions of channel 1 are routed to all slots and in addition tracked expressions are summed with the channels expressions.

    .

    One of its use-cases it to setup a SWAM Brass ensemble with six different brass instruments listening on different midi channels and panned to different positions - it sounds really fat when playing monophonic melody lines and still allows to play fat chords etc.

    I also did a SWAM String ensemble setup with 4 violins that sounded very cool - but i also had to tweak their settings add some external FX to make these sound like an ensemble.

    One rule of thumb for the Multi Divisi script is that there always should at about two more voice instances than the number of the average concurrent notes (# chord-notes) . The script supports note stealing etc, so its not a technical limititation - it just sounds fatter if several notes are play in unison.

    .

    I tried to do videos about both setups, but seem to fail again and again in their completion... that‘s why i now decided to do this post.

  • And i uploaded a ATOM Pattern Switcher & Randomizer script for Mozaic to PatchStorage :)

    Pattern switcher for Atom Pianoroll² with randomization to generate melody and beat variations.

    Direct the midi output of the script to a ATOM Pianoroll² instance that contains several pattern and dial the ﹟𝘱𝘢𝘵𝘵𝘦𝘳𝘯𝘴 Knob to the exact number of pattern used in the ATOM instance.
    Taping a 𝘗𝘢𝘵 # pad toggles pattern latching. If unlatched, the script can issue synced random pattern changes if configured.

  • I just uploaded v1.2 of Smart Chord Bass with a bug fix for state saving. Thanks to @ccs2 for reporting

    The previous v1.1 was released december 2019, quite some time ago. The bug itself was a simple typo

  • edited June 2021

    @_ki said:
    I just uploaded v1.2 of Smart Chord Bass with a bug fix for state saving. Thanks to @ccs2 for reporting

    The previous v1.1 was released december 2019, quite some time ago. The bug itself was a simple typo

    Yes, this is a good one.

    Sweet one Atom one too, great stuff.

  • @brambos Getting some unexpected behaviour with the Lydian scale. Set root to C and ScaleQuantize C yields D. Am I missing something or could this a bug?
    Also, any chance you could add in the Locrian scale, seems to be the only missing major mode.

    @OnLoad
      PresetScale 9
      SetRootNote 0
      Log (ScaleName 9) , { Quantize: }, (NoteName 0), { ==> }, (NoteName (ScaleQuantize 0), YES)
    @End
    

    Lydian Quantize: C ==> D-1

  • I suspect you’ll be told to implement Locrian either as a custom scale, or as a major scale with the root a semitone higher than your intended root.

  • edited June 2021

    edit: Sorry just woke up and totally misread this thread as the Rozeta thread. D'oh!

    Hi @brambos ! Since this thread got upped, wanted to put my request here:

    If possible, can Program Change be an option in LFO, along with the CC's? So one lane in LFO would just trigger Program Changes.

    I would really like to use that with a Critter & Guitari Eyesy. It would be a perfect companion piece with that capability. Thanks!

  • wimwim
    edited June 2021

    @CalCutta said:
    edit: Sorry just woke up and totally misread this thread as the Rozeta thread. D'oh!

    Hi @brambos ! Since this thread got upped, wanted to put my request here:

    If possible, can Program Change be an option in LFO, along with the CC's? So one lane in LFO would just trigger Program Changes.

    I would really like to use that with a Critter & Guitari Eyesy. It would be a perfect companion piece with that capability. Thanks!

    I can't imagine any app or hardware that wouldn't freak out at receiving the blast of PC messages that LFO would put out. Have you seen how fast those suckers come out? Even on a slow LFO speed, it's sending out repeated messages like every 10 ms.

    But, assuming the target could handle it, it's easy to convert cc to program change using Mozaic:

    Mozaic:

    @Description
    Demo - convert CC 13 on MIDI channel 1 to program change.
    @End
    
    @OnMidiCC
      if MIDIByte2 = 13 and MIDIChannel = 0
        SendMIDIProgramChange MIDIChannel,MIDIByte3
      else
        SendMIDIThru
      endif
    @End
    
    @OnMidiInput
      if MIDICommand <> 0xB0
        SendMIDIThru 
      endif
    @End
    

    It could be done in Streambyter as well.

    # StreamByter Demo: Convert CC 13 on MIDI channel 1 to program change
    B0 $13 = C0 X3
    
  • @wim said:

    @CalCutta said:
    edit: Sorry just woke up and totally misread this thread as the Rozeta thread. D'oh!

    Hi @brambos ! Since this thread got upped, wanted to put my request here:

    If possible, can Program Change be an option in LFO, along with the CC's? So one lane in LFO would just trigger Program Changes.

    I would really like to use that with a Critter & Guitari Eyesy. It would be a perfect companion piece with that capability. Thanks!

    I can't imagine any app or hardware that wouldn't freak out at receiving the blast of PC messages that LFO would put out. Have you seen how fast those suckers come out? Even on a slow LFO speed, it's sending out repeated messages like every 10 ms.

    But, assuming the target could handle it, it's easy to convert cc to program change using Mozaic:

    Mozaic:

    @Description
    Demo - convert CC 13 on MIDI channel 1 to program change.
    @End
    
    @OnMidiCC
      if MIDIByte2 = 13 and MIDIChannel = 0
        SendMIDIProgramChange MIDIChannel,MIDIByte3
      else
        SendMIDIThru
      endif
    @End
    
    @OnMidiInput
      if MIDICommand <> 0xB0
        SendMIDIThru 
      endif
    @End
    

    It could be done in Streambyter as well.

    # StreamByter Demo: Convert CC 13 on MIDI channel 1 to program change
    B0 $13 = C0 X3
    

    Critter & Guitari Eyesy which doesn't handle audio :) (video synth) I've been doing it now with a Squarp Pyramid to change scenes and it gives amazing results!

    Thanks for the script!

  • wimwim
    edited June 2021

    @CalCutta said:
    Critter & Guitari Eyesy which doesn't handle audio :) (video synth) I've been doing it now with a Squarp Pyramid to change scenes and it gives amazing results!

    Thanks for the script!

    The thing is, LFO doesn't just send out a single CC message only when the value changes. It sends out a constant stream of CC messages every 10ms or so, even if the value doesn't change. So, even if you have, say a really slow sample and hold LFO, you're not going to get a single CC converted to PC only when the value changes, but a blast of them all the time.

    Maybe it'll work for your app, but it seems like it could cause problems for most apps. If it does work, I think it would be very dependent on how the target app handles that kind of flood of messages.

    I hope it works out. If not, then some more code would be needed to filter out duplicate messages.

  • edited June 2021

    @wim said:

    @CalCutta said:
    Critter & Guitari Eyesy which doesn't handle audio :) (video synth) I've been doing it now with a Squarp Pyramid to change scenes and it gives amazing results!

    Thanks for the script!

    The thing is, LFO doesn't just send out a single CC message only when the value changes. It sends out a constant stream of CC messages every 10ms or so, even if the value doesn't change. So, even if you have, say a really slow sample and hold LFO, you're not going to get a single CC converted to PC only when the value changes, but a blast of them all the time.

    Maybe it'll work for your app, but it seems like it could cause problems for most apps. If it does work, I think it would be very dependent on how the target app handles that kind of flood of messages.

    I hope it works out. If not, then some more code would be needed to filter out duplicate messages.

    Look up the Squarp Pyramid. It sends PC's via-an LFO. Also, look up the Eyesy. Both these things are hardware, not apps. As well, the Eyesy just handles visual scene changes via-MIDI PC, and does not crash when getting PC's at a rapid rate from the Squarp's LFO (not audio rate but fast nonetheless).

    I have done this already many times and assure you it works fine, that's not under question. The only reason I don't want to use the Squarp for this all the time is I'd rather use the Squarp on audio synths as its way overpowered MIDI-wise for the Eyesy's needs.

    I have considered other options to replace the Squarp, and Rozeta's LFO is the best candidate. With an option to send PC's via-LFO, it would be essentially perfect for it.

  • wimwim
    edited June 2021

    @CalCutta said:
    I have done this already many times and assure you it works fine, that's not under question. The only reason I don't want to use the Squarp for this all the time is I'd rather use the Squarp on audio synths as its way overpowered MIDI-wise for the Eyesy's needs.

    I have considered other options to replace the Squarp, and Rozeta's LFO is the best candidate. With an option to send PC's via-LFO, it would be essentially perfect for it.

    Well, maybe the script will help. StreamByter seems to be a little more streamlined in this case once you wrap your head around its syntax. Good luck.

  • @wim said:

    @CalCutta said:
    I have done this already many times and assure you it works fine, that's not under question. The only reason I don't want to use the Squarp for this all the time is I'd rather use the Squarp on audio synths as its way overpowered MIDI-wise for the Eyesy's needs.

    I have considered other options to replace the Squarp, and Rozeta's LFO is the best candidate. With an option to send PC's via-LFO, it would be essentially perfect for it.

    Well, maybe the script will help. StreamByter seems to be a little more streamlined in this case once you wrap your head around its syntax. Good luck.

    Thanks! Keeping my fingers crossed that Rozeta adds my feature request but this is going to be a good way for me to sharpen my coding skills.

  • I have a launchpad mini mk3 that I’m using to control several drum machines from one grid. I’d like to be able to hold a MIDI momentary button and press one of the drum pads to mute that note (or unmute) but I can’t find any way of doing this practically. This is standard behavior in Ableton drum rack for instance, but Atom2 lacks this, and other drum sequencers I’ve found are capped at a low number of drum hits/notes.

    Anyone aware of a way to achieve this? I was thinking to use a Mozaic script for the “shift” behavior, and a series of MIDIGATEs plugins for octaves of drum kits to support setting probability to 0, but this is messy. Is there a nice way to do this with Mozaic alone?

Sign In or Register to comment.