Audiobus: Use your music apps together.

What is Audiobus?Audiobus is an award-winning music app for iPhone and iPad which lets you use your other music apps together. Chain effects on your favourite synth, run the output of apps or Audio Units into an app like GarageBand or Loopy, or select a different audio interface output for each app. Route MIDI between apps — drive a synth from a MIDI sequencer, or add an arpeggiator to your MIDI keyboard — or sync with your external MIDI gear. And control your entire setup from a MIDI controller.

Download on the App Store

Audiobus is the app that makes the rest of your setup better.

MOZAIC - Create your own AU MIDI plugins - OUT NOW!

18081838586102

Comments

  • One more @brambos story:

    I spent a few days making a sequence and today I discovered @brambos included an example script that work suspiciously like mine. This means I can read files without opening them. I won't read the @brambos code... I learn more by just hacking away making a script
    no programmer should ever read. @_ki saw one of my scripts and asked "Do you mind if I
    re-write this?" The ideas were interesting and he showed me why he gets paid to code.

    It's like playing chess... only most of us are using checkers rules and don't realize we never actually learned the rules. Still... I have a box of Queens and Kings that I have jumped over.
    Of course, I play white and black so I always win.

  • @Synthi I‘m making good progress at the multi-divisi script.

    I now have something running for 4 to 9 output slots that can cope with the notes played after the initial configuration. One can play normal, legato, or even issue note re-triggers during a single input timeframe. The output usually happens in the same timeframe/midi event‘s systemtime as the input event, even though the script first collects all input of a given input timeframe.

    Using heavy wiggling wih 4 fingers on AUMs keyboard, i manage to archive up to 17 midi events in a single event timeframe, lots of re-triggerin of the same notes or ‚short‘ notes with on/off/on/off states. The divisi output is still consitent even with such extreme input.

    I already did a hell lot of debugging: The internal state verification code is nearly as long as he other code, the internal state/the decisions/the changes etc are output to logging and if any inconsitency is detected, an emergency fullstop comes into play that stops any further processing.
    After inspection of these logs and states, i ususally come up with and idea what went wrong - i then change the slot distribution or midi analysis code and add even futher verfication tests.

    The cool thing is that i couldn’t yet ‚brake’ the current version :)

    There are still some features that i want to add to the script, like full MPE support for the input. But all the basic problems mentioned in my initial midi-divisi response are solved.

    .

    @McD :)
    I‘m not good at chess at all - even if i would play play both sides the game would either last until there are two kings left, or at some point I would decide to let other me win, or i suddenly notice that one of the kings is in check-mate and i don‘t know how i did that

  • @orchid said:
    Hey all, I just released 3 new plugins on Patchstorage:

    Gravity delay: https://patchstorage.com/gravity-delay/
    Panning gravity delay: https://patchstorage.com/panning-gravity-delay/
    Dedupe: https://patchstorage.com/dedupe/

    I recorded myself setting up the signal chain in AUM and playing a few notes into it:

    I’m having a ton of fun with these plugins. Let me know if you make anything cool with them, I’d love to hear :)

    These are really cool, Cheers @orchid

  • @_ki said:
    @Synthi I‘m making good progress at the multi-divisi script.

    I now have something running for 4 to 9 output slots that can cope with the notes played after the initial configuration. One can play normal, legato, or even issue note re-triggers during a single input timeframe. The output usually happens in the same timeframe/midi event‘s systemtime as the input event, even though the script first collects all input of a given input timeframe.

    Using heavy wiggling wih 4 fingers on AUMs keyboard, i manage to archive up to 17 midi events in a single event timeframe, lots of re-triggerin of the same notes or ‚short‘ notes with on/off/on/off states. The divisi output is still consitent even with such extreme input.

    I already did a hell lot of debugging: The internal state verification code is nearly as long as he other code, the internal state/the decisions/the changes etc are output to logging and if any inconsitency is detected, an emergency fullstop comes into play that stops any further processing.
    After inspection of these logs and states, i ususally come up with and idea what went wrong - i then change the slot distribution or midi analysis code and add even futher verfication tests.

    The cool thing is that i couldn’t yet ‚brake’ the current version :)

    There are still some features that i want to add to the script, like full MPE support for the input. But all the basic problems mentioned in my initial midi-divisi response are solved.

    That sound wonderful!!! ...you are a genius!
    Thanks a lot @_ki

  • edited March 2021

    @McD said:

    Deletion is life. It's all practice for the last act.

    😁 reminds me of https://deletionday.com, which is coming up soon.

    @Poppadocrock said:

    These are really cool, Cheers @orchid

    Really glad you’re enjoying them!

  • 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!

Sign In or Register to comment.