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
Agree, this is a tool that can be used for so many thIngs from correcting patterns programmed at double or half speed (I’ve wasted so much time in the past doing this) to getting weird out of sync stuff going.
I’m currently messing with my newly purchased TD3 and RD6 synced to Launchpad Pro and Launchpad app, I’m delighted that I can now use link to sync these to Cubasis for recording what I am doing
@LFS
The Drums pads in CB v3.4 are messed up and are scattered all over the place!
As per the GM standard layout, the Kick and Snare should be at the bottom-left. It's fine in v2 but v3 is messed up. There are other pads that are misplaced/invisible in v3.
AM House Kit 1 in CB v3.4 -
AM House Kit 1 in CB v2 -
Similar issues can be found in other MicroSonic drum kits like Studio Kit, Rock Kit, etc. in v3.4 to the point the Snare pads and some other pads are not even visible
compared to the Keys layout (which is fine).
There are 3 types of pads in v2 and 2 types of pads in v3 - Drum pads, Key pads and Chord pads. Apparently, you folks are sorting the Drum pads by the key name in v3.4. Sorting of pads by their name may be done only for Key pads and Chords pads. For Drum pads, they should not be sorted by their key names to preserve their positional integrity.
Why were the Key pads removed in v3 ?
Imagine if a manufacturer dishes out a keyboard that does not follow the General MIDI standard layout for percussion/Drums on the keys - that would be a chaos.
https://en.wikipedia.org/wiki/General_MIDI
Playing on Drum pads would be confusing and screen-recorded Drum video clips would look chaotic - in v3. Please resolve this.
Good point.
I would add being able to save an edited drum pad layout would assist a lot.
Agree!
We can reassign various drum parts to each pad in Edit mode and the layout gets saved on the current track only.
Feature to create our own reusable drum kit layouts using drum parts from the same drum kit or a drum sound library (similar to how it can be done in FLSM) or mix-n-match drum parts from various other drum kits into a new drum kit - is already on my bug list posted on Steinberg forum.
That’s why I mentioned being able to save our edited layouts so that we can use them in other projects.
Having to edit a layout for every project that uses the drum pads is tedious.
For instance I use several drum and percussion tracks per project and for each track
I have to either learn where the drum sounds are or edit the layout.
It’s much faster to learn where the drum sounds are than editing a layout per track.
By the time I’ve done a playable layout I’ve almost forgotten the parts that I need to play in.
And talking about saving layouts the same thing could be applied for the new chords feature.
Again a good point.
Added to the bug list.
@LFS
Congratz on the update. Unfortunately things like importing audio files directly to current selected/created folder still does not work.
A imported audio file always goes to MY AUDIO FILES.
User creates a folder or navigates to a folder.
User imports a audio file
User still has to navigate to ‘my audio files’ to manually move the files to prefered folder.
These are workflow 101’s that can make or break a workflow if you ask me.
There is no logic here. Not a single steinberg dev thinks of this ?
@LFS Cubasis 3.4 with multiple Beathawk AUV3 instances and multicore processing enabled make all Beathawk instances crashes one after one, audio first then UI become blank. With multicore disabled there is no issues.
Would you mind explaining what you mean by “repitching” vs time-stretching?. Is it just the algorithm or something different altogether?.
Well, modern 'time stretch' changes speed/duration of the sound without changing its pitch...
...while 're-pitching' changes playback speed to match the tempo by lowering or increasing the pitch.
(Think slowing down or speeding up a tape-deck or turntable).
AUMs file-player uses 're-pitching' when you change the tempo...
I see. So the “classic”way… the Digitakt does repitching and Drambo (via speed on Flexi) too. Sure it can be cool, specially on drums or short sounds. But personally If I could only have one it’d be the time-stretching. Guess it depends on the use case/type of music.
Thanks!
The thing is that re-pitching is a totally trivial operation (programming-wise), while time-stretching, especially when high-quality, is closer to noble prize complexity territory... that's why you'll probably find re-pitching more often 🙂
There shouldn't be any reason to not have both though.
Y'know, that could be a problem with BeatHawk. It might not be prepared to have two threads of itself running at once. There might be some common data that's not created separately for each AUv3 instance.
@LFS Any chance your team can fix mixing down to stems on the base ipad? I get no sound on tracks and wasted an 40 minutes troubleshooting only to find it wasn’t my AUV3s, its that the basic function doesn’t work.
Thanks just sent a report to UVI too @LFS
This must have to do with how you are using Drambo here. Are you using Drambo‘s sequencer for the kick? Maybe CB3 track freeze does not start Drambo‘s sequencer. Try creating a normal CB3 Midi part containing the notes for the kick.
High quality re-pitching aka vari-speed requires resampling in a fixed sample rate system… doing this at high quality is not quite trivial. Most samplers do no better than hermite interpolation which is no better than kinda OK.
.
OK -- my naive vari-speed implementation would probably just have been linear interpolation 😂 but still, time-stretching is a completely different beast, that was my main point... a trivial time-stretching implementation is impossible.
No it’s not, trivial time-stretching can granular-style - play enveloped snippets of sound so they cross-fade and move the play position around between grains.
(Yes, I once was a VST plugin dev 😂)
Well, the 'old-school' sample-offset & re-trigger is my favorite
On a side note, this video inspired me to connect a mouse to my Ipad. I have a keyboard already. Only thing is to connect the home button to a spare knob, and adjust movement and scroll speed and other minor tweaks.
What a joy for office work. So thanks! Without a keyboard I guess there is no real use for a mouse, it is all or nothing, no hybrid solution.
“So what we’re going to be using is percentage because it’s easier…..for me….ahem”
Hilarious.
That’s my approach to drambo.
Same here been using that in trackers for ages with the 9xx command (or equivalent) where each 'slice' * 256(0x100)samples long.
The resolution can get quite dense when using a synced ramp up LFO for Offset and something else to trigger them slices at 1/128 note intervals
But admit it, that is not as trivial as a single multiplication
I'm a part-time DAW-dev including all included plugins! Touché 😆
@LFS I've got a couple bugs to report that have been real workflow killers that I’m hoping can be squashed in a hot fix of some sort.
In the video above you’ll see that enabling the loop option after using atom piano roll 2 as a midi fx leads to a weird feedback. This has been very easy to reproduce and happens every-time I use atom 2.
Also, notes inside of the Cubasis piano roll intermittently disappear requiring me to to copy and paste the midi block in order to get them to appear again.
Thanks
Hi all,
Thank you very much for your positive feedback about Cubasis 3.4 so far!
We are more than pleased, that you seem to enjoy using the new update so far.
Please note that our engineering already reviewed your bug reports and requests, which we‘ve recieved through the Audiobus and Steinberg forums, via email or private message.
The team already started working on the next update, which aims to resolve the issues introduced with the release of V3.4.
Again, thank you very much for all your feedback!
Stay safe
& best wishes,
Lars
Hello,
I just posted about an issue I have with Cubasis 3.4 (has occurred with 3.3 as well) when using Koala sampler as auv3 on the Steinberg forum:
https://forums.steinberg.net/t/cubasis-3-huge-project-size-with-one-auv3-midi-track/765486
Sharing this here as well and tagging @LFS and @elf_audio.
Cubasis gets really unresponsive when I am working on a project with one midi track and an auv3 instance of Koala. The Koala project that I tested with was 134 Mb. This results in a Cubasis project file size of 403 Mb. In previous simple Cubasis projects having 2 Koala sampler instances and nothing else, where the total size of the Koala projects was around 200 Mb (199 + 1 Mb), the Cubasis project file size was around 1 Tb, making Cubasis very unresponsive and unstable.
I am aware of the auv3 memory limit of ~360 Mb. I would however assume that loading a 134 Mb or even 200 Mb Koala project would still be ok.
Also, I do not understand the huge Cubasis project file sizes when using Koala auv3. Does Cubasis save the auv3 state including Koala sampler's audio and not just a reference to the Koala project? Still the resulting file size for the Cubasis project is three-fold.
I am using an iPad Pro 12.9 1 Tb 2018.
cheers!