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.
just got Auria Pro and EG Pulse, some things i cant figure out
i’ve ran into blockades i can’t figure out.
when i try to open et pulse as an interapp audio it never opens, i get an error message asking to try to open the apps in a different order, i’ve tried all possible orders it just never works.
when i open pulse as an auv3, it works fine, except that i can’t use the pulse interface (16 pads) to input midi into the auria track, sometimes a midi note or two will be recorded (weird) but randomly, it works fine with the auria keyboard/pad window, but it isn’t ideal because i much prefer to use the pulse pads.
thanks ! i feel like i’m pretty close to getting what i want from the apps.
Comments
When you are using Pulse as an AU in Auria Pro, do you have it set as the track's instrument or as an insert on the effects chain?
as an instrument, just like i would do in logic x
... but i did try the other way just for curiosity, didn’t work either way.
I just tried it both ways and it didn’t work for me either. A few taps were recorded but most weren’t. Frustrating. Worth reporting to both developers.
I just checked and it looks like EG pulse is sending 3 note off events for each pad tap. I suspect that is part of the problem.
perhaps, but eg pulse works perfectly in garageband and zenbeats.
I suspect it's because you have the pads set to Shot mode. If they're in one-shot then they send a note-on / note-off sequence too rapidly for some hosts to detect. You have to change them to "Hold". The problem with this is you'll get the notes cut off on playback if the note isn't long enough. So ... then you need to switch them back to Shot, or have two kits, one with each setting.
IMO it would be better if with MIDI Out, at least a minimum 1/32 note would be sent, or maybe an option for that. Something to ask @ElliottGarage for, I think.
The problem happens in hold mode, too. i suspect the extra note off events are the problem though I could be wrong.
I just tried recording EG Pulse in Auria Pro - and in my case it only recorded notes when in the FX slot, but many notes tapped on the pads were missing.
Next thing i added was a simple (newly written) Mozaic script into the next insert FX slot to prevent double note on/off :
Voila, all notes - even fast hi-hats were recorded by Auria. BUT as Mozaic does not forward audio during recording no sound was to be heared (its a midi-only plugin after all). To replay the recorded sequence i had to bypass Mozaic.
@ElliottGarage
The above test confirms that it’s the double note-offs send by EG Pulse that hinders correct recording in Auria Pro.
Further investigation checked the timing of NoteOn versus Note-Off:
EG Pulse sends the first of its NoteOffs in the exact same timeframe as the NoteOn - this can lead to errors for other DAWs or midi recorders.
.
I also verified that using any midi-only plugin in the insert slots of Auria Pro after the instrument blocks the audio (this should be fixed in AP, but currently i‘m too lazy to write another bug report), so adding a double note protection via scripting is no usable workaround.
I reported this ages ago. Long before the latest update.
Here I am, when pad are set to one shot Pulse should send one single noteOff right after the noteOn. If the pads are set to HOLD the noteOff will be sent at the pad release.
I don't have Auria so I cannot test it, but on Garageband and Cubasis 2 it works as I reported.
In AUM, if I send the pulse output to a midi monitor, I see multiple note offs for each pad tap in both hold and non-hold mode. I believe this was reported in another topic's thread also. Are you using your current internal version or the App Store version?
@espiegel123 I'm checking it with the help of @_ki
If the pad is set to one shot Pulse sends a noteOn and a noteOff in the same stream (but the noteOff has a midi timestamp delayed). This happens also on the noteOff when you release your touch, so you have noteOn+noteOff (with delayed timestamp) on touch down and noteOff+noteOff(timestamp delayed) on touch released.
On the contrary if you set the pad to HOLD it send just one single noteOn on the touch down and one single noteOff on the touch released.
Probably Auria ignores the MIDI noteOff timestamp and this creates the issue. I cannot recreate the problem on Cubasis or GarageBand.
Eventually I can try to see what happens if, when in One shot mode, I sent the noteOff only on the pad touch release
Lots of apps, and all hardware, don't pay attention to the time stamp. Standard MIDI doesn't even have a timestamp. IMO best to send it as a separate event with at least a few ms delay between the two.
I just checked Hold mode behavior in AUM:
Pressing the pad sends a single note-on, releasing the pad (about a sec later) send the note-off (ie a note on with zero velocity). Seems okay.
But trying the same in Autia Pro (pressing pad in Hold mode) still does not record - only if i add my ‚double note protector script). I‘ll now do further tests in Auria, what might cause the problem
I added logging to my ‚DNP‘ script, as in AUM EG Pulse only sends a single note-on on press and a note-off on release, no idea yet why this is not picked up by Auria Pro.
On non-hold mode, there are definitely three note offs for me in AUM for each note on. One happens almost immediately. The other two happen on release:
It seems like in Hold mode I was mistaken and only one pair is sent.
Ok, i found something:
Mozaic automatically converts Note-On velocity zero into real ‚note-off‘. Streambyter does not.
9X XX 00 = 8X # // Convert note-ons with vel 0 to note-offAuria Pro was recording the pads with hold mode
To conclude:
-> Auria Pro does not convert the ‚note-on vel o‘ midi message to note-off (which is in midi standard btw), so for EG Pulse better send a true note-off command and hold mode will record even in Auria Pro.
.
Regarding the multiple note-offs of the shot mode - please only send a single, true note-off when the pad is released. If such midi is played back, the pads audio will be the same (pad plays full sample), so it does not matter ‚when‘ the note-off is issued (when reading the midi back). But as you see it matters for recording or using EG Pulse pads to play other drums/synths. The multiple note-offs are not standard, especially the note-off, note-off combination currently send on pad release (while in shot mode)
I also found a work-around for recording pad-play as midi in Auria Pro with audio. Add the following 3 plugins
After recording, you can disable the script plugin and second instance, so that the first one plays the recorded midi. You can also switch back the pads modes to shot after recording.
.
StreamByter script:
Mozaic script
@_ki : Are you sure that Auria can’t deal with note on 0 as a note off from other plugins? I was under the impression that it did.
Me too, but i just tested that adding the one-line script to StreamByter enabled recording. Without the conversion, Streambyter is fully transparent (every input is directly output) and nothing was recorded in Auria Pro.
Note-on with velocity zero is valid midi standard for sending a note-off. I don‘t know how else i generate this (my external keyboard send a true note-off). I think about a test...
I just sent notes from the AUM keyboard which uses velocity 0 for note off and AP recorded the notes correctly.
I now also tried with my keyboard first going into AudioBus in a Streambyter converting the true note-offs to note-on vel 0 (verified by a second StreamByter inside AP) and from there into Auria Pro => i was able to record such midi in AP, so i can confirm your test @espiegel123
I then analyzed APs stored notes using another streambyter inside the track and they are received as true ‚note-offs‘ there .
So it‘s still mysterious, why conversion to true note-offs fixes recording of pads in hold mode for EG Pulse.
Maybe there is something else to the midi messages (perhaps the ‚timestamps‘ ?) that is removed when sending the midi first through a midi plugin ? But then just applying StreamByter without the conversion script should do the trick, which it doesn‘t....
Maybe passing through Streambyter is acting as a buffer for the two EG Pulse events that are relying on the delayed timestamp, and converting them to two separated events that AP can deal with. In other words, maybe Streambyter is able to deal with the timestamp to separate the events and AP isn't.
Perhaps a way to test that would be to script it so that the two events are processed in Streambyter, but the zero velocity note-on isn't converted.
@wim I verified that (and showed in a picture abov) that in hold mode, only a single note-on is send on press and at another timestamp a note-on with velocity zero (which midi defines as note-off) is send by EG Pulse.
I now also re-verified that just inserting StreamByter without the conversion script does not record (tried with single EG Pulse plus StreamByter, so one doesn‘t head audio) . When adding the single line script, recording works.
.
Better work-around found:
Additionally i discovered that using the ‚StreamByter (Instrument)‘ variant of the plugin instead of the ‚StreamByter‘ variant will forward the audio - no need for a second EG Pulse instance to hear the performance while recording. Pads need to be in hold mode and StreamByter needs to run above conversion script - otherwise recording does not work.
.
BTW: If a StreamByter without script is inserted, the effect of ‚recording not working‘ should better be described as: ‚Only the first press of each pad is recorded with an infinite small note-length‘ - in contrast to not record any notes at all, if StreamByter is not present. So there is a different behavior when a midi plugin is inserted into the output stream of EG Pulse - maybe it‘s the timestamps which are too internal to be shown by midi debuggers ?
OK, but none of my comments have been concerning hold mode, only non-hold mode. I believe the root of the issue is here:
Whether or not AP being able to handle the simultaneous(?) messages relying on timestamp (which doesn't exist in actual MIDI), it's just not good practice IMO. Hardware doesn't even know such a thing exists, and not all apps pay attention to it either. Timestamp is meant as an enhancement to improve timing, not something to depend on.
But ... I'm armchair quarterbacking here. You're the ones doing the actual testing. So I'll bow out.
@wim I‘ll try your idea now - not modify the note-on vel 0, but pick it up and simply delay it a tiny fraction.
@espiegel123 Perhaps the note-on vel 0 conversion only applies to external midi sources, not if they are generated in the fx plugin chain ? Both your and my test only covered external midi. I will write a simple StreamByter script that sends out note-on and later note-on vel-0 on button press to verify this new hypothesis.
@wim We are on the same boat - for shot mode i already recommended that EG Pulse no longer sends note-on and note-off in the same timeframe and also that the release of a pad should no longer send these double note-offs. I assume recording will work a lot better when the pads in one-shot mode just behaves like in hold mode.
I assume that EG Pulse will react the correct same way to that midi in one-shot mode, start the sample playback on the note-on, and continue even if the note-off is received before its end (like with input from AUMs keyboard)
The closeness in time of the note on and note off could be an issue. There is a another app that sends them so close together (or used to) that a handful of synths would have problems.
I say all this having run into issues and having measured dropped midi messages in AUM when sent too close together from Mozaic some time ago. The conclusion by the developer at the time was that the messages were all being passed, but that plugins were unable to process them. I now always include a short random delay from 1 - 10ms whenever firing messages off that could happen simultaneously. There could be two parallel issues, lack of timestamp recognition, and messages incoming too rapidly to process.
I remember some other mention in relation to problems StepPolyArp Unit, that some apps can miss multiple messages in the same render buffer, or something like that ...
OK, I'll exercise some discipline now and truly bow out. We're kinda OT to the OP at this point anyway.
@espiegel123 I just confirmed with a simple StreamByter script, that Auria Pro does not record note-on vel 0 as note-off inside the midi plugin chain. The Lyra Sampler correctly recognizes this and stops its note, but this is still not recorded.
The note-on vel 0 conversion only seems to work for external midi. Maybe i will report this to the Auria forum tomorrow...
Nice detective work! Please do let them know over on the AP forum.
really digging these plot twists