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!

1414244464784

Comments

  • @winconway said:
    Actually I made a mistake in my explanation, offset needs to be +1

    This would be the dials.....
    Number of notes in the Round Robin, as is now.
    Round or Random Robin, As is now.
    Offset, This would offset the input note by the number of notes in the round robin +1, so for example if you trigger a C4 and the Number of notes was 2 it would send C4/C4# in the Round Robin, But if you trigger a C4# it would offset the input up to D4# (Up 2 notes+1) and send D4#/E4, so that there is no note overlap.
    It may need a root note being set for the base of the offset, in this example it would be C4.

    I hope that makes sense ?

    Sorry, I still don't fully understand the algorithm here.

    Is it...

    • receive input note
    • if the offset > 0 calculate a second input note based on the offset
    • send both notes into the round-robin algo
    • send out both notes
      ?

    Perhaps it would help me if you could explain the use case of the offset parameter?

  • I just uploaded a script to patchstorage.com called MuteMIDI. The purpose of the script is allow/deny MIDI getting from a source to a destination based on the setting of Pad 0 and a control note received on MIDI in. MIDI notes 0-11 are reserved for the script’s use.

    Further documentation is in the script’s comments.

    In addition to being on patchstorage, here’s a link to the file on DropBox:

    https://www.dropbox.com/s/9qsytmg5doue4n3/MuteMIDI.mozaic?dl=0

  • So I'm adding CC recording to Flow and it's super-duper-fun to have.
    But, right now I'm recording CCs on each "part" of the sequencer (every step in the sequencer has 8 parts, so 16*8 parts per sequencer loop).

    For "fast" sequences, say step lengths of 1/8 at 120 bpm this works great. For slow ones where every step is 1-2 bars, not so much as midi output will be stepped and for example a filter cutoff jump for each part change.

    Any of you clever Mozaic brains out there that has a suggestion for clever interpolation of CC output?

    Timers with interpolation in OnTimer?
    Higher PPQN and interpolation in OnMetroPulse?
    Or maybe a bunch of SendMidiCC with clever delay to fill the gap between parts?

    Or maybe @brambos has some clever SendInterpolatedMidiCC function brewing :smiley:

  • @Peblin All three variants are valid and good ideas.

    I didn't yet measure the impact of higher ppqn, but if the code inside does run only sparsely (not on every of the pulses) then i didn't notice an impact. I have some scripts running with a ppqn of 384 which is about one event call about every msec.

    Same for fast timers. I just checked that all timer-events are called and none is omitted even for 1msec timer interval. (i just increment a var in OnTimer and output every OnHostBar running with 120bpm which equals 2000msec ) The 1ms timer runs with stable 2005 incs, perhaps the host tempo is not correct ? A 10ms timer results in the expected 200 calls. AUMs dsp is showing 2% with 1msec timer, so there isn't a big hit.

    The idea with the pre-delayed CCs is nice (and easy to implement), but could result in CC changes after the host stopped.

  • edited August 2019

    @brambos sorry if you already decided on this or not, but would you consider making maximum array size 1024 instead of 1000? 8x8x16 has a TON of musical applications.

    Sincerely, someone who just bought a novation launchpad ;)

  • @brambos
    It's probably been reported, if not - releasing shift outside the button doesn't trigger @onshiftup

  • @burns_audio said:
    @brambos sorry if you already decided on this or not, but would you consider making maximum array size 1024 instead of 1000? 8x8x16 has a TON of musical applications.

    Sincerely, someone who just bought a novation launchpad ;)

    It is a fun little curiosity how 4:4 music gets related to bits and bytes counting in multiples of 8/16/256/1024 :-) But yeah, 1024 is probably more useful than 1000 as that randomly picked limit, in this world of 4:4 and 16 steps music.

    I have considered a launchpad XL for some time (just waiting to see if it gets updated with bluetooth). Some useful Mozaic scripts utilizing it would surely tip me over!

  • @_ki said:
    @Peblin All three variants are valid and good ideas.

    I didn't yet measure the impact of higher ppqn, but if the code inside does run only sparsely (not on every of the pulses) then i didn't notice an impact. I have some scripts running with a ppqn of 384 which is about one event call about every msec.

    Same for fast timers. I just checked that all timer-events are called and none is omitted even for 1msec timer interval. (i just increment a var in OnTimer and output every OnHostBar running with 120bpm which equals 2000msec ) The 1ms timer runs with stable 2005 incs, perhaps the host tempo is not correct ? A 10ms timer results in the expected 200 calls. AUMs dsp is showing 2% with 1msec timer, so there isn't a big hit.

    The idea with the pre-delayed CCs is nice (and easy to implement), but could result in CC changes after the host stopped.

    Thanks for the feedback! I've implemented the "pre-delay" solution for now - it works like a charm and eliminates the need for quite a lot of state-keeping when several patterns are re-playing CCs at the same time :wink:

  • @brambos said:

    @winconway said:
    Actually I made a mistake in my explanation, offset needs to be +1

    This would be the dials.....
    Number of notes in the Round Robin, as is now.
    Round or Random Robin, As is now.
    Offset, This would offset the input note by the number of notes in the round robin +1, so for example if you trigger a C4 and the Number of notes was 2 it would send C4/C4# in the Round Robin, But if you trigger a C4# it would offset the input up to D4# (Up 2 notes+1) and send D4#/E4, so that there is no note overlap.
    It may need a root note being set for the base of the offset, in this example it would be C4.

    I hope that makes sense ?

    Sorry, I still don't fully understand the algorithm here.

    Is it...

    • receive input note
    • if the offset > 0 calculate a second input note based on the offset
    • send both notes into the round-robin algo
    • send out both notes
      ?

    Perhaps it would help me if you could explain the use case of the offset parameter?

    Hopefully that explains it, Five Round Robin pairs, each pair is triggered by a single note, but it needs to be offset.

  • @winconway said:

    @brambos said:

    @winconway said:
    Actually I made a mistake in my explanation, offset needs to be +1

    This would be the dials.....
    Number of notes in the Round Robin, as is now.
    Round or Random Robin, As is now.
    Offset, This would offset the input note by the number of notes in the round robin +1, so for example if you trigger a C4 and the Number of notes was 2 it would send C4/C4# in the Round Robin, But if you trigger a C4# it would offset the input up to D4# (Up 2 notes+1) and send D4#/E4, so that there is no note overlap.
    It may need a root note being set for the base of the offset, in this example it would be C4.

    I hope that makes sense ?

    Sorry, I still don't fully understand the algorithm here.

    Is it...

    • receive input note
    • if the offset > 0 calculate a second input note based on the offset
    • send both notes into the round-robin algo
    • send out both notes
      ?

    Perhaps it would help me if you could explain the use case of the offset parameter?

    Hopefully that explains it, Five Round Robin pairs, each pair is triggered by a single note, but it needs to be offset.

    The number in green in the offset?

  • edited August 2019

    No, I just loaded up the kit I need it for in Slate in Nanostudio 2, those are the pad numbers, its just a screen grab that I have overlaid pad notes and trigger notes.
    I thought that explained it, sorry, I will have a rethink about how to better explain it.

  • Is the bottom left quadrant correct, where F#1 is supposed to be triggered by F#1 with no offset?

  • edited August 2019

    @winconway Reading your original description and looking at your diagram, I think the offset is RR_SIZE * (note - ROOT). Where RR size is 2 in this case and the root is F#1.

    So playing A#1 triggers group offset = 2 * 4 = 8

    Group 1 + 8 = Group 9

  • edited August 2019

    @bleep said:
    Is the bottom left quadrant correct, where F#1 is supposed to be triggered by F#1 with no offset?

    Yes thats why I thought it would need a root note dial.
    In this case it would be F#1 as the root.

    F#1 in to Mozaic would send F#1/G1 out of Mozaic as the two Round Robin notes.

    G1 in to Mozaic would send G#1/A1 out of Mozaic as the two Round Robin notes.

    G#1 in to Mozaic would send A#1/B1 out of Mozaic as the two Round Robin notes.

    A1 in to Mozaic would send C2/C#2 out of Mozaic as the two Round Robin notes.

    A#1 in to Mozaic would send D2/D#2 out of Mozaic as the two Round Robin notes.

    So a Root dial to set the first incoming note that the offset will be based on, in this case F#1, then the offset is the number already set in the Round Robin number (In this case it would be two as can be seen above, each hit has two RR)

    So F#1 plays two notes in the Round Robin F#1/G1 which is how it currently works, because F#1 is set as root, but because the offset setting is on, when Mozaic recieves an input of G1 it shifts the output up by one to G#1/A1, when Mozaic recieves G#1 it shifts the output up by two to A#1/B1, when Mozaic recieves A1 it shifts the output by three to C2/C#2, and when Mozaic recieves A#1 it shifts the output by four to D2/D#2.

    Hopefully that is a bit clearer ?
    @brambos

  • @Peblin said:

    For "fast" sequences, say step lengths of 1/8 at 120 bpm this works great. For slow ones where every step is 1-2 bars, not so much as midi output will be stepped and for example a filter cutoff jump for each part change.

    Any of you clever Mozaic brains out there that has a suggestion for clever interpolation of CC output?

    You might want to take a look at this: CC Processor, in particular the Slew Limiter section. It may be just what you’re looking for.

  • I uploaded a new version of Clusters with a few tweaks to the Shift key code. Let me know if the issue persists. I couldn’t find any obvious issues with my code, so I’m not sure why the Shift key intermittently stops working. I wonder if there might be a bug in Mozaic’s timer, but I haven’t been able to nail anything down to say for sure...@brambos, any ideas? I have had a lot of problems with the interpreter throwing up a bunch of bogus errors when I upload code; sometimes it takes several tries to get it to upload cleanly.

  • @bleep said:
    Those who were interested in the Olafur Arnalds piano tech discussions earlier should check out the Clusters script. Thanks for that one, @Bryan!

    Yes, I should mention that Clusters was originally inspired by Olafur Arnalds. It’s evolved a lot since that initial inspiration, so I can’t say it’s a clone of his software (which I don’t have access to anyway), but rather an attempt to capture the spirit of his idea.

    https://youtube.com/watch?v=vAj1SwPKfqc

  • @Bryan said:
    I uploaded a new version of Clusters with a few tweaks to the Shift key code. Let me know if the issue persists. I couldn’t find any obvious issues with my code, so I’m not sure why the Shift key intermittently stops working. I wonder if there might be a bug in Mozaic’s timer, but I haven’t been able to nail anything down to say for sure...@brambos, any ideas? I have had a lot of problems with the interpreter throwing up a bunch of bogus errors when I upload code; sometimes it takes several tries to get it to upload cleanly.

    I will check it out. FWIW, the shift key never worked for me, but I have enjoyed using Clusters nonetheless.

    Is there a way to select which Voice is used? I was checking out the presets in a session and it seems like when I used the same preset in another session it was using a different voice pad and resulted in different note selections with the same settings. Probably user error on my part.

  • @Bryan said:
    I uploaded a new version of Clusters with a few tweaks to the Shift key code. Let me know if the issue persists. I couldn’t find any obvious issues with my code, so I’m not sure why the Shift key intermittently stops working. I wonder if there might be a bug in Mozaic’s timer, but I haven’t been able to nail anything down to say for sure...@brambos, any ideas? I have had a lot of problems with the interpreter throwing up a bunch of bogus errors when I upload code; sometimes it takes several tries to get it to upload cleanly.

    I just downloaded the new version.

    When I used it the shift key was not working at first. I went into the code and added a Log call in OnShiftDown and OnShiftUp and magically the shift key started working even though the only thing that I did was add the log call which should not have affected anything.

    It seems like how long the shift key is down influences whether the shift up is detected. I just notice that if I tap the shift key quickly, it switches to expert mode but if I hold it down longer it doesn't.

  • @espiegel123 said:

    @Bryan said:
    I uploaded a new version of Clusters with a few tweaks to the Shift key code. Let me know if the issue persists. I couldn’t find any obvious issues with my code, so I’m not sure why the Shift key intermittently stops working. I wonder if there might be a bug in Mozaic’s timer, but I haven’t been able to nail anything down to say for sure...@brambos, any ideas? I have had a lot of problems with the interpreter throwing up a bunch of bogus errors when I upload code; sometimes it takes several tries to get it to upload cleanly.

    I just downloaded the new version.

    When I used it the shift key was not working at first. I went into the code and added a Log call in OnShiftDown and OnShiftUp and magically the shift key started working even though the only thing that I did was add the log call which should not have affected anything.

    It seems like how long the shift key is down influences whether the shift up is detected. I just notice that if I tap the shift key quickly, it switches to expert mode but if I hold it down longer it doesn't.

    Weird. I just removed the two log calls and the shift key stopped working. Adding them backed solved the problem.

    @brambos: is it possible that there is a race condition and that somehow having that simple log line somehow prevents the race?
    I simply added log {shift is down} and log {shift is up} as the first line (where there was a blank line) in OnShiftUp and OnShiftDown respectively.

  • @espiegel123 said:

    When I used it the shift key was not working at first. I went into the code and added a Log call in OnShiftDown and OnShiftUp and magically the shift key started working even though the only thing that I did was add the log call which should not have affected anything.

    It seems like how long the shift key is down influences whether the shift up is detected. I just notice that if I tap the shift key quickly, it switches to expert mode but if I hold it down longer it doesn't.

    Weird. I just removed the two log calls and the shift key stopped working. Adding them backed solved the problem.

    @brambos: is it possible that there is a race condition and that somehow having that simple log line somehow prevents the race?
    I simply added log {shift is down} and log {shift is up} as the first line (where there was a blank line) in OnShiftUp and OnShiftDown respectively.

    I think you may be on to something. I've had the same experience where adding a log call will mysteriously get something working again. As you said, this shouldn't matter but it seems it does. I'm glad you mentioned it because I'd had this happen a few times and thought I was going crazy.

    I've also had some luck re-uploading the code (sometimes I must re-upload multiple times because the interpreter throws up a bunch of bogus errors; e.g., it might throw up a syntax error in OnAUParameter even though I'm not using the OnAUParameter event in my code). So I have no idea what the issue might be. It's above my pay grade, it seems. Hopefully @brambos has some ideas.

  • @Bryan said:

    @espiegel123 said:

    When I used it the shift key was not working at first. I went into the code and added a Log call in OnShiftDown and OnShiftUp and magically the shift key started working even though the only thing that I did was add the log call which should not have affected anything.

    It seems like how long the shift key is down influences whether the shift up is detected. I just notice that if I tap the shift key quickly, it switches to expert mode but if I hold it down longer it doesn't.

    Weird. I just removed the two log calls and the shift key stopped working. Adding them backed solved the problem.

    @brambos: is it possible that there is a race condition and that somehow having that simple log line somehow prevents the race?
    I simply added log {shift is down} and log {shift is up} as the first line (where there was a blank line) in OnShiftUp and OnShiftDown respectively.

    I think you may be on to something. I've had the same experience where adding a log call will mysteriously get something working again. As you said, this shouldn't matter but it seems it does. I'm glad you mentioned it because I'd had this happen a few times and thought I was going crazy.

    I've also had some luck re-uploading the code (sometimes I must re-upload multiple times because the interpreter throws up a bunch of bogus errors; e.g., it might throw up a syntax error in OnAUParameter even though I'm not using the OnAUParameter event in my code). So I have no idea what the issue might be. It's above my pay grade, it seems. Hopefully @brambos has some ideas.

    bram, i am on 12.3.1 with iPad 6th Gen if that helps

  • @espiegel123 said:

    bram, i am on 12.3.1 with iPad 6th Gen if that helps

    Same.

  • I’m looking into it!

  • @brambos, I noticed a small typo in the program and in the manual: In the CustomScale command there is a missing comma between <c#> and .

  • I just uploaded another attempt at getting the Shift key working consistently in the Clusters script (version 1.0.2). Let me know if the problem rears its ugly head again.

  • @Bryan said:
    I just uploaded another attempt at getting the Shift key working consistently in the Clusters script (version 1.0.2). Let me know if the problem rears its ugly head again.

    I think I just tried it (downloaded 10 minutes ago, 1.0.2).
    SHIFT didn’t work for me until I removed the Log {} statements in OnShiftUp/OnShiftDown/OnTimer.

    :scream:

  • @peplin, Thanks for taking the time to test it. I'll keep messing around, but at this point I'm really stumped. If anyone has any ideas, I'm open to suggestions.

  • It sounds like it’s something on my end. Let me look into it.

  • @brambos thanks bram. I've also experienced several instances where adding/removing "NOP"-style code lines affect how the code runs so something's fishy somewhere. :smile:

    Oh, and please, pretty please, pretty pretty please, do consider a CurrentTimeMillis call. It would help me SO MUCH to be able to do Log {MetroPulse started: }, CurrentTimeMillis then Log {MetroPulse ended: }, CurrentTimeMillis to profile my event handling. I'm really struggling to figure out how to profile my code and get it to use less DSP.

Sign In or Register to comment.