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.
I didn’t test with Velocity Keyboard yet. I used the AUM keyboard.
II’m glad the OnTimer code works so easily. I never used it in this context before. It’s a joy when something you don’t completely understand just works.
I’ll map the variables to knobs and maybe add that decelerate feature too.
Pitch bends should not make a difference since they just pass through Mozaic without changes.
Just tried Native Instrument Santoor with midi sent from iPad using VelocityKeyboard (pitch bend turned off). I have some suggestions which I did DM you to make it sound more realistic.
I do seem to recall some kind of issue with Mozaic processing a high rate of pitch bend messages from Velocity Keyboard, but I don't remember much else about it. I may have worked around it by having Mozaic send out the most recent pitch bend message once per millisecond, or maybe the problem occurred when Mozaic received the pitch bend messages, and I didn't find a solution.
Hi, I was wondering if this is possible to do in Mozaic.
Situation: I have a midi driven matrix switch distributing 8 channels of audio which are going to different FX upon every new preset (next song) I'm using 8 physical faders which send out CC's to control the volumes + 16 push encoders for 8x solo and 8x mutes. Because every new preset has different routings to different FX, the end mixer (AUM) is naturlly corresponding to new routings which is quite impossible to remember from top of your head, as the FX device positions have changed.
A solution would be to directly engage with the levels on all synths so everything would correspond to the right devices even though the routings have changed.
In order to do this Mozaic would have to have state memory of the last received CC's (incoming faders for DB)
as an example:
when Mozaic's upper Pad 1 is a Solo of drums, then it mutes the risidual 7 channels + remembers the last received value from the fader, followed by everything returning to the previously stored position after unSoloing.
When muting Pad 1, the CC value gos to 0 and unMuting returns it to the last stored value, would this be anywhere near realistic to achieve?
If I understand what you want correctly from my brief initial reading, then https://patchstorage.com/controller-tracker-and-snapshots/ might help, or be something that could be modified to suit.
The script remembers the last value of everything that is passed through it. When you save the AUM session all those values are saved with the script state. When you restore the AUM session all those values are sent out. You can also save individual "snapshots" of the settings for special cases.
You should also check into MIDI Busses in AUM. They can also help a lot when you have changing routings by putting a level of abstraction between the controller and what it controls at any one time.
thank you @wim I was already using that script for something else! meanwhile after a long fiddle I solved the above in SB
Hello, I would like to use my midimix with this 'memorization' patch.
It works well, but of course the values on my midimix are not updated.
Is there a preset (I searched in vain) that catches the values from the restored value and does not take into account the value of the midimix ??? (i use aum)
I store the value of 127.
I move my midi cc to 10 on my midimix.
I click on 'Recall' => The value on my synth is now 127.
But if i move my knob midimix, it restart at 10, so i have a jump form 127 to 10 :-(
I would like the preset to wait for the midimix to return to 127 before modifying the value
I have this on my tr8s : 'knob mode=> catch'
Thank you ! (sorry for my english ...)
@biggir - what you’re referring to is also often called “pickup mode” or “takeover mode” and it’s always a problem with controllers with apps that don’t have that feature.
It’s possible to make a script ignore values until the existing value is crossed. I might consider extending this one to be able to do that, though that use case isn’t what it was designed for. It was meant for controllers that have endless encoders and that can set their knob position based on midi feedback.
It’s a little bit tricky to implement this “catch” behavior, so I can’t say for sure if / when I might find the time to do that.
Very sorry if this has been asked before but is there a script that creates chords out of a single note sequence send into Mozaic?
Can you be more specific? Do you mean “play a note and have the Mozaic script play a chord based on it”? Or “play a few notes and have the Mozaic script put them together into a chord”?
The Chordulator does the first one. The second would require much more information about how you would want it to work.
The first. Thank you very much
@wim , wow that would be great! and I think it could be useful to many, since these controllers are not too expensive, I would serve you as a tester with pleasure 😊
There's a problem with this. To implement a pickup mode requires detecting when the knob has passed through the value that you want to catch. Detecting that is no problem - just look at the values as they approach the pickup point and only start sending values when that point has been reached.
The problem is when the controller knob is equal to the pickup point to begin with. The script has no way of knowing where that knob is until it starts sending values. But if it's already on the same value as the pickup point, so it won't trigger the pickup.
Let's say the target value is 64.
If the knob starts below 64 we just ignore values until the value is 64 or greater. Or the opposite if it's above 64. So far no problem.
But if the knob is at 64 it's a problem. The knob doesn't send anything until you move it. That's going to be a value above or below 64, but not 64. So we don't know whether or not to pick it up.
If the knob is already on the "pickup" value, it will have to be turned off of the pickup value in either direction, then back through the pickup value in order for anything to happen. The result is you get no output from the knob unless you jog it a little bit to one side or the other of the value, and then back the opposite direction.
I see no way around this.
@wim, I store the last known value in an array. If the next value is 1 or 2 away from the last stored, I start sending/consider the “pickup” triggered. If it’s more than that, I wait for it to be crossed.
It’s not perfect, but it works for my use cases. I log/store pretty much every CC anymore weather I need it or not, from both the controller and the software (if it’s smart enough to send midi)
Yeh, I guess that'll have to be good enough. Thanks.
Nope. Turn a knob fast enough on a NanoKEY Studio and it can skip four or more values. Could be only that controller, but one can't assume that.
I'll have to ponder whether I feel like releasing something using the other method but requiring a slight jog if the controller happens to be on the saved value when it's first moved. It goes against my sensibilities though.
I think if I decide to do it, I'll make it a separate script that can be chained before or after this one. I don't like dropping sub-optimal solutions into something that I'm otherwise happy with.
Yeah. Could be the controller. Could be just how u naturally crank knobs.
It would take some adjustment to make it work for you. Most of what I have that on is things that don’t need major sudden movements, like ripping a volume from 10 to 100 (and missing that 1-2 buffer)
I don't want to do something that only works for me or might work in certain situations. It either has to work consistently in all situations or not. The "jog a little if the value is exact on startup" approach would work consistently at least.
I guess I'll compromise and add a check on just the initial controller movement and consider it a pickup if the value is 2 or less away from the original, but not at other times.
I know…just throwing out suggestions
Thanks. Yeh, that was actually helpful. I think that solution is one I can live with.
@sujoybose77 requested a "trill" script on a thread and we worked together to design and implement one in Mozaic.
I call it "Tremolo v1.0" because "trill" implies alternating with a neighbor tone in Western Musical Notation. Tremolo is repeating the same note.
It's available for download from patchstorage:
Hello, I found in GrooveRider a 'Catch' mode, I'm very happy with it :-) If all apps could implement it ! unfortunately this is not the case, maybe soon ;-)
It rare for apps to do it and/or support encoders. This is why I just log everything, handle it myself, and stop pestering devs about adding it
If you care to post a tidy, single purpose script for handling catch mode to patch storage, I'm sure people would find it very useful. I can't seem to gather much enthusiasm in myself to do it.
thank you for making available all these scripts that I use very often, it's great! :-)
Thanks for saying that @biggir.
@wim I’ll try and get something there, but it’s the start of my busy season.
Basically for the logging part I just use 16 arrays, 1 for each midi channel (e.g midich0, midich1,…)
The I just log all incoming midichX[midibyte2] = midibyte3 (cc# lines up with the array index with its value). Just made the mental gymnastics easier for me when sending
I usually just substitute the array value and send straight from it, or I attempt to overwrite the value on the controller itself (with sysex or whatever if the device supports it)
I try and avoid pickup if I can, but sometimes controllers just be dumb like that.
Edit: I also need to stop “ducking” around w/ mozaic/sb for this controller stuff and take the next step
@AlmostAnonymous - maybe I'll throw something up there after all. It really shouldn't take much time and would be pretty darn useful as long as it's kept simple. It turns out I've got some time on my hands atm.
Thank you very much for your „Simple Scaler“ script. Unfortunately polyphonic aftertouch data is not affected …
You're right. I never considered the need for it. I'll open that one up again.