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 StoreAudiobus is the app that makes the rest of your setup better.
Comments
I feel your pain. If you're serious about making complex Mozaic apps here's some cheap advice:
Use an iPad Editor. @_Ki made a Mozaic scripting syntax checker for Textastic but any editor suitable for your needs would work. When you want to run some code use "Select All" + "Copy" (Control-C is often provided).
Then open the edit in Mozaic. Find a blank line to double click and choose "Select All" then use "Paste" to insert your revised code into the Mosaic editor and hit "Upload".
I usually use the "Save" button at this point and maybe update the filename with an increment to the file name revision extension.
You can also transfer text back into the editor of your choice.
This sounds ponderous but it beats all the editing in the Mozaic code text editor which has
no productivity tools like a decent text editor.
NOTE: Apple never intended to have anyone write code on IOS. Real IOS programmers use Xcode on a MacBook and even run their test applications on the Mac Book and install in the IOS device only for usability testing.
Slowly Apple will have to make IOS a much more capable device.
I found an iVim IOS app but the font is so small I won't use it.
Textastic supports ssh; ing into another server and then you could run a Linux editor there
like Vi or Emac (on OS X for example). The text copy -> paste and save in Mozaic is the
key to avoid editing in that silly little text box.
Please share your progress and let's let @brambos make another amazing IOS music tool and not re-invent the text editor.
Maximum number of code lines is 2,500. Maximum number of variables, 200. I believe this is for performance and memory reasons due to limitations of the OS.
@Tim6502 there is a setting to disable the "." shortcut.
There are also other keyboard choices, such as Gboard, Swiftkey, or maybe DevKey. I use Gboard and would be interested in knowing how other options perform.
Thanks, @McD! Mostly have been using vi on Windows/Linux and copy-pasting to iOS. Though, as always, there are late fixes and changes on the iPad side. Probably not ready to go textastic, but will try to incorporate iVim as it does have the 'right' esc-key feeling on its keyboard and I do not find its font much of an issue.
Appreciate the reminder on general options, @mojozart - this was a real iOS duhhh moment for me!
I have now disabled most of the 'smart' stuff, since I prefer to be in full control of my text.
@wim - I think that Bram may have slightly upped the number of (array) variables to 256 or so, recently.
Though I think that one could overcome this limit -at least for scalar constants or variables- by mapping them to array elements which are expanded out by a macro-processor for the final program.
So 10 variables would become 10240 scalars, which is plenty to work with.
A 2500 line limit is actually much more bothersome to me. Still curious what that is based on - the text editor, the generated code, or the size of the source code included in the preset? (If the latter, that could be stored in compressed format, no?)
Long story, but it has to do with how difficult it is to make a virtual machine real-time safe (i.e. you can't dynamically allocate memory etc.). So anything that needs to be both "unlimited" and "realtime" is practically an issue inside an AUv3 context.
It seems like 2,500 is roughly the number of lines required to cause potential glitches when pasting code into, and using, the built-in editor. I just now attempted to paste 2,700 lines into the editor, and 2,608 lines transferred properly. When the paste function works, the program still runs, but the built-in code editor becomes glitchy. If there's a hard limit of 2,500, then I don't understand the mechanism. Maybe it's more of a general rule-of-thumb, a rough estimate, because we wouldn't want a bunch of scripts that can't be studied and edited.
I understand that the size of the Mozaic VM needs to be fixed at runtime, @brambos. And you are computing the set of variables that are used when translating the source - as these are also placed in the preset to be recalled.
So are you limited to a one-size-fits all model for the VM at all times, or would one be able to increase the VM-size during UPLOAD (i.e. translate time) when it is determined that the script is using more variables than were used previously? Uploading a new script would not appear to be something that requires real-time response. (And no need to give the memory back when the script becomes smaller - one can re-load in a new instance.)
So if memory allocation is possible for the uploads, the VMs could be made no bigger than required for the script - on the con side, one might need to pre-parse the source to determine VM requirements.
I just uploaded a new "channel rotation, mono to poly" solution, similar to Polythemus but with a new improvement: It rotates channels in order to allow the note decays to ring out properly, and it also skips channels on which a note is already being held. Pitch bend messages output to the channel with the most recently-struck note.
It's a component of my upcoming microtonal app, which I'm now hoping to release early next week. Enjoy!
https://patchstorage.com/poly-it-up-channel-rotator/
@Skyblazer Thanks for the nice script, very usefull.
... and it spares me from porting over my StreamByter 'Distribute NxM' script
I made some modifications for better handling when the channels are all used-up. You got a PM explaining the changes and attached script, feel free to incooporate them (or not)
That's a nice gesture: modify the script but let the coder decide how to take the input. I hope
it helps and we all benefit.
Has anyone else found Mozaic to occasionally lose track of where the next bar is, and which beat is which when running multiple instances within AUM? For some reason if I’ve stopped and started the host a few times, often the instance of Mozaic I’m relying on to start doing something @OnNewBar starts running those events as if the new bar started on the 2nd 3rd or 4th beats...
I haven't seen this behavior before. Let me look into it.
Great thanks! Lemme know if more details would be helpful.
If you have a script you are willing to share which exhibits the issue that could be helpful.
Yeah sure, I’m just running the Simple Recorder/Looper 1.1 by @H_Basilier with some slight modifications just to ignore recording notes from certain channels, but otherwise the same as on PatchStorage
I am running a few other simple scripts as well in separate instances of Mozaic, modifying some of the messages before being sent to the Simple Recorder/Looper, and these instances will also sometimes lose track of the bar, which I got around by using a simple Timer counting 1-4 starting at @OnHostStart, but of course that limits my use of the timer for other things, which in the case of the looper patch is critical.
Ok, clear. Thanks!
Is there a Mozaic script that can pull a bass line out of a chord progression? Like a reverse “The Chordulator” script. Maybe even able to set how many notes from the incoming midi chord are played (1-4) to create simple or more complex bass lines. With transposing, and maybe some strum, Arp, and randomization?
Could the Copy Cat script do this...?
I mean.... Could the Copycat script kind of do this?
Yes. Try:
:ifont 1 20
Also:
:help :ifont
Thanks. I hope I can make it huge. I tried on my iPhone and no go.
iPhone 5SE:
@Poppadocrock CopyCat copies a specific input midi stream to other channels and applies modifications.
If the inout consists of three-note chords and one defines to drop more than 33% the chance is high that only one of the chords notes will go through, but its not guaranteed to be the bass note.
@rs2000
Thanks. I was using “Vim” and NOT “IVim”. Big difference in the keyboards so I saw the error of my ways. Works great.
Side thought re: multiple timers. If I need more than one timer, I just use an array:
@_ki Gotcha. thanks.
@Poppadocrock
Yesterday evening i did some tests regarding ‚extract bass note from chord‘ . The main problem is that the notes arrive sequentially at the script. And since they might arrive out of order, the detected lowest note will change while the chord is arriving. The script would need to delay the bass note output until analysis is done. Otherwise it would send out the wrong note and stop it right away, replacing it with a new lower note that arrived at the next
@OnNoteOncall during the same ‚outside’ multi note midi event.I checked the timing for 3 note chords, all of them arrive at the same MetroPulse and SystemTime when feed from a sequencer. But one still would need to add a slight delay of either 1 pulse (≈ 1.5msec @ 120bpm) or 1 msec by a timer (needed if the host is not running) to determine the lowest note of all input notes.
When playing manually (and intentionally a bit sloppy) using AUMs on screen keyboard, the time between first and last note of a chord in some cases got as high as 20 msec. To be sure to catch the correct bass note, all output would need to be delayed by this 20 msec - but inducing such a big latency before sending out the the important bass note would destroy the whole timing of the song.
Another idea to overcome the ‚delay’ problem could be to use a pre-determined, configurable max note number for all chords - in that case, the bass note could be send out immediately when the number of chord-notes is reached. The drawbacks of this method are that one simply can‘t add a 4 note harmony to a mostly 3 note chord progression without risking to select the wrong bass note, and when sliding a chord on the AUM keyboard quite often the note-off for keys will arrive after the note-on for the new keys resulting in temporary >3 note chords which need to be addressed.
.
Also the scripts reaction to note offs has to be though off - should a new lowest bass note be send out if a 4 note chord is reduced to a three note one ? Should there be an analysis delay to check if perhaps all notes are released ?
.
It seems the whole ‚extract bass note from chord‘ problem can‘t be fully solved without some restrictions.
(@Brambos For this use-case, two new Mozaic variables specifying the number of note-ons and note-offs still in queue for this timestep would help to get rid of the delay. The script could send the bass note of all active notes when the last of all the incoming notes for this timestep is processed.
Such variables would aid in chord processing in
OnMidiInput,OnMidiNoteOn,OnMidiNoteOff. At least the number of queued (and still to be delivered) events is already there somewhere in the internal Mozaic event processing code, but i suspect these both numbers are too special to be published as Mozaic functions named for instanceQueuedNoteOns/QueuedNoteOffs)I wrestled with this same thought process when asked for a script to strum and otherwise alter incoming chords. The problem is how to reliably detect chords when you don’t know that all the notes will be received simultaneously. But it’s worse than that because chords could also overlap.
Personally, I don’t think this is a good use case for Mozaic unless Mozaic itself is generating the chords.
Indeed, a chord played live will have all notes come in at different times (milliseconds between them). I.e. Mozaic will never automatically register this as a chord unless you do some clever tricks.
Just quickly thinking out loud (if quantization is acceptable):
Perhaps something like that could be a starting point?
If one samples the notes in OnMidiNoteOn / OnMidiNoteOff, but issue the output notes in OnMetroPulse every 1/16 or 1/32 the output will be off by that amount because the OnMetroPulse event fires before the 0nMidiNote events - so one always misses the ‚on point‘ incomming notes.
Additionally, usage of OnMetroPulse limits to use-cases where the host needs to be running.
This is true. I suppose you could do a really fast
@OnTimerinstead, but overall I agree with @wim that this is perhaps not the best use case for Mozaic unless you are willing to live with some timing-tradeoffs.