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!

15051535556102

Comments

  • By all means put them in one script :smile: @ManWhoWouldBeStrings
    That will be easy realy.

    If you have nice functionality usefull for other applications then maybe it would be nice to make separate modules.

  • About the code:

    I would test for
    If midicommand = 0x90, instead of if midibyte1 = 144.
    But there is a big change you will receive another noteOn with velocity 0, wich is a noteOff.

    So this is weaponing you against noteOffs retriggering your script:

    If midiCommand = 0x90 and midiByte3 > 0
    If midiByte 2 = sendTrigger

    Elseif midiByte2 = myOtherTrigger

    Endif
    Endif

  • wimwim
    edited November 2019

    @ManWhoWouldBeStrings said:
    I have a few more general questions (rather than concerning the stuff above in my last post) regarding what is a more efficient way to setup a few simple scripts running in AUM for controlling Loopy in interesting ways.

    Is it better to:
    embed each of the fairly simple codes I’ve got going into one longer script
    OR
    load multiple instances of Mozaic with the separate scripts

    For me it’s all about what plays out as the most easily understandable, and therefore manageable solution. I’m more comfortable with code that I feel I understand and that I don’t get lost in the complexity of. Everyone has their own tolerance for that. Mine is about 10% of what the real pros around here can handle.

    On the other hand, I would rather have one plugin that can do five things I want rather than five plugins cluttering up a setup, as long as I still feel like the plugin code is manageable for me.

    And with multiple instances of Mozaic, is it better to:
    Load them all in a chain in one AUM channel
    OR
    Give them each seperate channels

    It really doesn’t matter. Even if they’re all loaded into a single channel, they’re not “chained” unless you set the routing up that way. I’d usually rather have all of them in a single channel so that I don’t have to do as much scrolling.

    On the other hand, it’s sometimes nice to have the instance that’s controlling something next to what it’s controlling. That can help with remembering what controls what, and can also reduce scrolling when you’re focused on one app.

    So basically ... it really depends on what is most clear for you in both cases. It shouldn’t have any effect on performance or anything else.

  • _ki_ki
    edited November 2019

    @ManWhoWouldBeStrings However there’s something going on with the script you wrote @_ki which I can’t figure out, which is that it is always sending 0x14 (the note stored in the trigger[0] array) on ‘memory recall’...

    I didn't test the code, just tried to figure out what you presented and then refactored it. Maybe i have just missed that feature. Adding an if loopy[_idx] … endif inside the recall should fix that.

    Your repeat … until loop seems ok. If the number of iterations is fixed, i prefer to usefor loops, as these are not only 2 lines shorter (no init or inc statement) by also indicates that the looped statements never influence the end-condition and therefore will always terminate. A 'while' type loop should be used if use-case includes that the looped-statements are never executed , a 'repeat' type loop should be used if the use-case includes that the looped statements are at least executed one. Both 'while' and 'repeat' loops are prone to the endless loop error (just forget to increment) .

    However I was just thinking...in your opinion would it be a good idea to JUST use one of the Pads like you suggested, midi-bound to a command (the same sendtrigger) in AUM, and so just use the OnPadDown - Call@RecallTracks instead of testing for the note itself? One less thing to test for?

    Yeah that's a good idea, needs less code and is less error prone.

    .

    Is it better to:
    embed each of the fairly simple codes I’ve got going into one longer script
    OR
    load multiple instances of Mozaic with the separate scripts

    As the others already commented - It depends. I normally try to 'offer a well-rounded package', a script that covers all use-cases i can think of, but does not suffer from feature bloat and is still easy to use.

    .

    And with multiple instances of Mozaic, is it better to:
    Load them all in a chain in one AUM channel
    OR
    Give them each seperate channels

    I combine them in one AUM midi channel since this results in less scrolling. There is no disadvantage in doing so if the mozaic scripts use SetShortName and therefore have different icon names. My CopyCat script even allows to adapt the icon name with a knob since it is a regular use-case to have several of them.

  • edited November 2019

    @Alfred said:
    About the code:

    I would test for
    If midicommand = 0x90, instead of if midibyte1 = 144.
    But there is a big change you will receive another noteOn with velocity 0, wich is a noteOff.

    You can safely test for NoteOff messages. Mozaic will catch any NoteOn messages with a velocity of 0 and pass them on to you as a NoteOff message for your convenience. No need to design for this yourself.

    I have made a note of this behavior in the "Receiving MIDI in Mozaic" chapter in the manual, so you can assume that Mozaic will always offer this behavior.

    :)

  • Yup, my bad. Did not realize this was inside a onNoteOn handler. The testing for midiByte1 = 144 threw me off.
    In that case to make the code more clear, you are essentially testing: if midiChannel = 0

  • hello,
    in the mozaic manual i cannot find info how to setup and use a timer...
    can you please direct me to some example code?
    thank you

  • @rototom said:
    hello,
    in the mozaic manual i cannot find info how to setup and use a timer...
    can you please direct me to some example code?
    thank you

    Check out the example in Chapter 5 about using LFOs. It shows how to use a timer to get LFO values at set intervals.

  • @brambos said:

    @rototom said:
    hello,
    in the mozaic manual i cannot find info how to setup and use a timer...
    can you please direct me to some example code?
    thank you

    Check out the example in Chapter 5 about using LFOs. It shows how to use a timer to get LFO values at set intervals.

    ok, thanks. got it
    so there is only one timer possible per instance?

  • edited November 2019

    @Alfred said:

    In that case to make the code more clear, you are essentially testing: if midiChannel = 0

    Yeah you’re totally right about that. Still learning all the commands...

    In the end I’m now using OnPads (bound to trigger notes in AUM) to trigger the reset and recall so don’t need to test for any note input on any channel anymore anyways for that case. But thanks for the clarification. Also the clarification of how/when to use the different loop commands was very helpful @_ki. I was confused about that. But I think I’ve got this one nailed down now!

    And thanks @wim and @_ki too for the input on multiple instances of Mozaic or just one, and where to put them. I think in the end I’ll try for one instance to just do a bunch of basic conversions (note/cc transposing, note to program change/cc and vice versa, etc.) and a second instance with the various manipulations of those messages for controlling Loopy. All in one channel in AUM to simplify scrolling.

  • found a way to crash Mozaic this morning @brambos. Seems a long array initialization will crash the instance like this

    @OnLoad
    MACHINES = [1, 2, 3, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28,32, 33, 34, 35, 36, 37, 38, 39,48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63,64, 65, 66, 67, 68, 69, 70, 71, 72]
    @End

  • @burns_audio said:
    found a way to crash Mozaic this morning @brambos. Seems a long array initialization will crash the instance like this

    @OnLoad
    MACHINES = [1, 2, 3, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28,32, 33, 34, 35, 36, 37, 38, 39,48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63,64, 65, 66, 67, 68, 69, 70, 71, 72]
    @End

    @_Ki slipped me a clue about really long arrays:

    MACHINES [0] = [1, 2, 3, 16, 17, 18, 19, 20, 21, 22]
    MACHINES [10] = [23,24,25,26, 27,28,32,33,34,35]
    MACHINES [20] = [36,37,38,39,48,49,50,51,52,53]
    MACHINES [30] = [54,55,56,57,58,59,60,61,62,63]
    MACHINES [40] = [64,65,66,67,68,69,70,71,72]

    Maybe that will be a workaround? I tried to insert some HEX in the middle and that is a no-no.

  • @McD Hex constants should work where ever constants are allowed. In Mozaic these start with the prefix 0x :

    TEST[0x20] = [0,1, 0x42, 4]

  • @burns_audio said:
    found a way to crash Mozaic this morning @brambos. Seems a long array initialization will crash the instance like this

    @OnLoad
    MACHINES = [1, 2, 3, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28,32, 33, 34, 35, 36, 37, 38, 39,48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63,64, 65, 66, 67, 68, 69, 70, 71, 72]
    @End

    Looking into it! Thanks!

  • @brambos In addition to the "large array on load" crash, I've also experienced difficulty in storing and recalling five digit pitch bend values in a large array. I could experiment to figure out exactly what causes it; I just worked past it by storing a separate value for the ten thousands and thousands places. If I could load an array with 127 numbers, 5 digits each, on load, that would be convenient for making the code for my microtonal script a little bit nicer to read.

  • edited November 2019

    @Skyblazer I believe the max values in the arrays go from -64 * 127 to 64 * 127.
    So deducting 64 * 127 from your values would make them fit in one instead of two values.
    Also no pitchbend will be 0, so much easier to read :-)

  • @brambos thanks! I have another one for you although this one might be user error. I would expect the following to emit a random number from 0 to 1 but it seems to ignore the parameters when they are enclosed in parenthesis.

    @OnLoad
    log random(0, 1)
    @End

  • @burns_audio said:
    @brambos thanks! I have another one for you although this one might be user error. I would expect the following to emit a random number from 0 to 1 but it seems to ignore the parameters when they are enclosed in parenthesis.

    @OnLoad
    log random(0, 1)
    @End

    That should be

    Log (Random 0, 1)

    The entire function call should be enclosed in parentheses, not just the parameters.

  • edited November 2019

    @brambos said:
    That should be

    Log (Random 0, 1)

    The entire function call should be enclosed in parentheses, not just the parameters.

    Ugh.. thanks. I keep forgetting that part of the syntax when i leave mozaic for a few months and come back.. thanks!

  • @Alfred said:
    @Skyblazer I believe the max values in the arrays go from -64 * 127 to 64 * 127.
    So deducting 64 * 127 from your values would make them fit in one instead of two values.
    Also no pitchbend will be 0, so much easier to read :-)

    Thanks for the info, and that's a good idea. The topmost range of the pitch bend value won't be used, after all. The default bend value is 8192, "(64 * 127) + 64", so I'll subtract that from the total to make the default bend value 0.

  • Hi @McD

    I have been looking at your developments.
    I think Bill Evans was right about the joy of finding things out by yourself.
    I am a little concerned about the notes though, so here are some tips.

    You can split the onmidiInput into onmidinoteOn and onMidiNoteOff.
    You can store up to 16 notes for any input note in the noteState array.
    You can use the noteState array to release the right notes on noteOff.
    You can use onTimer and a counter to walk through the 16 notes in the noteState array.

    I think the long delay some notes get at the moment is not a sure method.
    This depends heavily on the midi buffer of the host.
    Using the onTimer method does not overload the buffer with future notes...

    First get the releasing of the notes working. Then you might try to also play the notes from the onTimer script. This way the added delays will be minimal.
    You will have to track multiple notes, so it will get a bit more complicated. But you will figure it out, once you build the release routine.

  • McDMcD
    edited November 2019

    @Alfred said:
    Hi @McD

    I have been looking at your developments.
    I think Bill Evans was right about the joy of finding things out by yourself.
    I am a little concerned about the notes though, so here are some tips.

    You can split the onmidiInput into onmidinoteOn and onMidiNoteOff.
    You can store up to 16 notes for any input note in the noteState array.
    You can use the noteState array to release the right notes on noteOff.
    You can use onTimer and a counter to walk through the 16 notes in the noteState array.

    I think the long delay some notes get at the moment is not a sure method.
    This depends heavily on the midi buffer of the host.
    Using the onTimer method does not overload the buffer with future notes...

    First get the releasing of the notes working. Then you might try to also play the notes from the onTimer script. This way the added delays will be minimal.
    You will have to track multiple notes, so it will get a bit more complicated. But you will figure it out, once you build the release routine.

    Thanks for your input. I'll use this as a list to work from as I go from v1.x to a 2.x version. I'm learning new things by (unintentionally) starting and putting out small fires in my script. My ability to process text on IOS has been the main takeaway.

    Thank God (or @_Ki) for Textastic and it's search/replace functionality. I'll bet there are a lot more text processing aids I have stumble on yet. I really miss my "vi editing" habits for using regex map statements. Is there a good "Vi Editor" app for IOS? Hmm... (Seems like there might be one that's FREE with IAP's).

  • Yes carefully chosen variable names make your script self explaining. Regular expressions are above my paygrade though. Ki is the master in that field. My experience with coding comes from HyperCard and Director.

    This guy has a nice perspective on coding:

  • _ki_ki
    edited November 2019

    @McD Textastic supports regex in search and replace - but i didn't try it out yet :)

    @Alfred Using the note state array to store the scheduled notes is a nice idea, but i assume that one could just use a normal array with a stride of entries offset by 16 for several input notes instead. That would result in 64 parallel active input notes with 16 arped / strumed / iterated chord notes each - which should be enough. Using the note state array offers 128 x 16 notes.

  • @_ki said:
    @McD Textastic supports regex in search and replace - but i didn't try it out yet :)

    What I'm craving is an editor that supports the Vi "escape" sequences for moving the cursor
    rapidly around the code without having to touch the screen or grab the mouse. Jumping to instances of a given variable I can type: :/ChordVolume{return} and continue using :/{return}

    I downloaded iVim but the font size is too small. I'll keep re-programming my brain to use Textastic unless someone proposes a useful "Vi" alternative for iPad editing. Can I add a font to iVim that's larger?

  • Just published my In-Order ARP script on patchstorage.

    • In-Order ARP all active notes from all channels, special support for MPE
    • Update active notes during play, you can release hold notes and add new ones to the ARPed set
    • Arped notes use their original channel and note velocity
    • Midi Through all CCs, ATs, PBs on all channels
    • Divisions selected by pads: 1/2, 1/4, 1/8, 1/16, 1/32, plus triplets and dotted variants
    • Gate length selection between 1-100% of note division
    • Velocity humanization 0-50 %
    • Pause / continue arping using the ARP OFF pad
    • State-Save the current setting (division, gate-length, humanization and on/off-state)
    • Easteregg special feature :)
    • Automation via AU parameters
  • Brilliant execution of some great ideas. I love your application of the SHIFT button.

    You are the King of Mozaic Tiles, IMHO and the Emperor of StreamByting.

    You asked if there would be any interest in you creating Mozaic Coding Videos and
    I vote "YES". The potential audience will only get larger with more of these amazing tools.

    Hopefully, more musicians will decide to try to invent their own automatic MIDI generators and utilities.

  • Thanks for the flowers, a less big bouquet would have done it too :) There are several excellent Moazic script programmers, from which i also learn and adapt.

    .

    You asked if there would be any interest in you creating Mozaic Coding Videos and I vote "YES".

    I already tried that with one of the next script ideas - but i totall disliked the result. I didn't image that i produce so many errors during scripting and tap stuff in the wrong order during testing. Over and over even though i have a clear idea what i wanted to do instead. And i learned that when talking during programming, i start swearing when bugs happen :o If i just code quietly i never had the tendency to curse myself, i just fix the many bugs i make.

  • @_ki said:
    There are several excellent Moazic script programmers, from which i also learn and adapt.

    I'm sure you know who's the real deal and who's a wanna be hacker.

    @McD wrote:
    You asked if there would be any interest in you creating Mozaic Coding Videos and I vote "YES".

    @_Ki replied:
    I already tried that with one of the next script ideas - but i totall disliked the result.

    Your best use of time is writing more scripts.

  • Mozaic is a brilliant Midi scripting system - thanks so much, @brambos!

    Two quibbles with the editor (which maybe comes as stock functionality from Apple and thus not fixable - though perhaps could be 'externalized' as an option):

    • when I put in more than one space character, it drops in a dot ('.') - this might have been fine in the old COBOL days, but not in any other programming language (well, there is PROLOG).
    • cannot do larg-ish programs: after copy-pasting content, scrolling down get's me stopped at a black hole, where the code just drops off. I would like to not chop up my 600k scripts. :)
Sign In or Register to comment.