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.

ravenscroft piano nit working in nanostudio 2

anybody else having trouble with ravenscroft piano not working in nanostudio 2? i loads up but is very crackly and unusable.

«1

Comments

  • edited February 2019

    i made one track using ravenscroft piano on iPad Air 1 and didn't experienced any crackles... But as first i disabled app build in reverb which is very CPU consuming - i use build in NS reverb...

    But i did read in other thread here at AB that somebody had issues with ravencroft crackles also in other host app - so probably there is smne issue with that app...

    what ipad do you have ?

  • i have an ipad pro, but not sure what version it’s a few years old. yeah i saw that persons review too, and haven’t had any problem with ravenscroft in any other apps. it’s very odd. i’ll have to check my settings maybe i’m missing something > @dendy said:

    i made one track using ravenscroft piano on iPad Air 1 and didn't experienced any crackles... But as first i disabled app build in reverb which is very CPU consuming - i use build in NS reverb...

    But i did read in other thread here at AB that somebody had issues with ravencroft crackles also in other host app - so probably there is smne issue with that app...

    what ipad do you have ?

  • I have an old pro (much like myself...), but have had no probs with the Raven in NS2....

  • This comes up a lot. From the FAQ Thread:

    Q: Why are IOS DAW's so fragile? Everything crashes around me when I make my projects. Who tests these Apps we pay so much for? Apple? The Developer? No. It's me!

    A: Think of an App as an appliance like these analogous electrical devices:

    • A Hairdryer (1000 Watts/10 Amps needed)
    • A drill (100 Watts/1 Amp needed)

    Most home systems in the use allow up to 15 Amps to be pulled from a plug (power strips can have 8-10 ports) before the line draws too much current and needs to throw the breaker to prevent the wiring from melting due to heat.

    2 hair dryers can't use the same power strip but you could use 14 drills (using 2 power strips into a power strip for 19 free ports)

    So, thought experiment, using Apps:
    1. iSymphony Strings 10 Amps
    2. Perfect Piano 7 Amps
    3. Tiny Pianos .3 Amps

    NOTE: DAW's need Amps too.

    Try using iSymphony Strings and the Perfect Piano at the same time. They crash the DAW (10 + 7 = 17 Amps. BREAKER)

    Use 2 Pianos without issue but probably little else at 14 Amps

    Switch to 30 Tiny Pianos... 9 Amps.

    "Now why does the Perfect Piano I paid $50 for crash in my DAW and the $5 Tiny Piano work? Doesn't Apple test this crap? I want my money back."

    Apple tests the breakers for AU's at 340MB - they try to help. I'm only considering one resource in my analogy. Most DAW's show CPU use but few show RAM and the interplay between RAM and CPU is exactly what the DAW is managing for you to create.

    So, most DAW on IOS complaints are due to resource limits. More RAM and faster CPU's provide more resources and Apple appears to be raising the AU resource limits for newer iPads since they have 4GB's. The big dog has 6GB for $2000.

    It's not a problem with IOS. It's just a boundary condition on a mobile device. Just seek a compromise with the Apps you love (understand their needs) and try not to throw the breakers and ruin your work with outages. It is a challenge worth the effort.

    There are many rules to live by but these are my top 3:

    Freeze heavy RAM/CPU Apps to audio early (free up RAM/CPU use)
    Don't expect a project to support 10-15 AU apps (if they do it's a "Tiny Piano")
    Try to Apply FX carefully to avoid wasting excess resources when they could be grouped or applied in post production.

    NOTE: Many Apps are synths/FX/Sequencer combos (I'm looking at you Aparillo). They are definitely Hairdryers. More and more we're getting seduced by hairdryers. So, things will only get worse without knowledge of this limitation and a plan to get work done. Apple can't fix this either. Just buy the fastest iPad to get more power.

  • edited February 2019

    @eross Hm on iPad Pro it should definitely work - at lest until you don't load 10 instances of plugin :)))

    Is it dropping even if you use in project nothing else just single instance of Ravenscroft ?

    What audio buffer you use ? Try go to settings and set audio bugger to "high" .. What does CPU meter when you hear those drops ?

    (CPU meter in NS is in settings, at bottom of screen where is also audio buffer settings)

    Apple tests the breakers for AU's at 340MB

    It is even worse. Apple sets this limit for ALL instances of same plugin - so if you run for example 3 instances of Ravenscroft, they all together share just 340 MB !

  • @dendy said:

    Apple tests the breakers for AU's at 340MB

    Good point. After a couple of days you can't change a comment or re-order them so it's not as precise as it could be. But RC275 has a history of crackling if you load a lot into a DAW. Stand-alone is great but in a DAW it can be tricky so recording some MIDI and then load RC275 and it the DAW supports it Freeze to audio. NS2 will add audio sometime this year or 2.

  • Not crackling for me in NS2 2017 iPad Pro 13”

  • tjatja
    edited February 2019

    @dendy said:
    It is even worse. Apple sets this limit for ALL instances of same plugin - so if you run for example 3 instances of Ravenscroft, they all together share just 340 MB !

    This is realy totally stupid :o :/ :o :/ :o :o

    Can't our resident developers not try to get Apple change that?

    It kind of totally nullyfies the purpose of AU :| :| :|

  • @tja said:

    @dendy said:
    It is even worse. Apple sets this limit for ALL instances of same plugin - so if you run for example 3 instances of Ravenscroft, they all together share just 340 MB !

    Most devices have 1GB of RAM. Newer iPads and iPhones have 2GB or more. There's the newest device with 4GB that costs $2,000. How much RAM do you want for AU's? 1/3 for most 1GB devices seems reasonable. I still use my iPad 2 with 512MB for somethings. Most AUv3 won't work with IOS 9 so there's that restriction due to progress.

    It's not a conspiracy to keep anything from you. It's an attempt to make a stable platform.
    Use Standalones or IAA apps and you another set of restrictions. I'd like to use multiple
    IOS devices using IDAM to avoid D-to-A conversions but I need something like iConnect4 with USB support to route the traffic. It will also probably be buggy anyway. Putting the code of 3 or more people iso a system is usually tricky unless someone sets out standards for interoperability and Apple tries to do just that.

  • @McD I was tempted to copy and paste your article. Lol

  • tjatja
    edited February 2019

    @McD said:

    @tja said:

    @dendy said:
    It is even worse. Apple sets this limit for ALL instances of same plugin - so if you run for example 3 instances of Ravenscroft, they all together share just 340 MB !

    Most devices have 1GB of RAM. Newer iPads and iPhones have 2GB or more. There's the newest device with 4GB that costs $2,000. How much RAM do you want for AU's? 1/3 for most 1GB devices seems reasonable. I still use my iPad 2 with 512MB for somethings. Most AUv3 won't work with IOS 9 so there's that restriction due to progress.

    It's not a conspiracy to keep anything from you. It's an attempt to make a stable platform.
    Use Standalones or IAA apps and you another set of restrictions. I'd like to use multiple
    IOS devices using IDAM to avoid D-to-A conversions but I need something like iConnect4 with USB support to route the traffic. It will also probably be buggy anyway. Putting the code of 3 or more people iso a system is usually tricky unless someone sets out standards for interoperability and Apple tries to do just that.

    I totally don't get what you are saying.

    As you write yourself, there are very different devices, from 0,5 GB to 6 GB.
    It is not the job of Apple to cripple ANY application or type of application with such artificial memory constraints!

    1) There is no need for any restriction at all.

    If you do not have enough RAM, read the error message and either buy a device with more RAM, or don't use the App.
    That works since the first computers on any operations system that ever existed.
    And it is a totally perfect solution.

    2) Apple makes this much more "criminal" in applying the same memory to any and all instances of the same App!

    I cannot even comment on this.
    It is the most stupid thing I ever heard about.
    Even with 6 GB, you can only run 1 instance????
    This even makes the 6 GB device useless for lots of usages.

    Drop any and all of such restrictions!
    Those with fewer RAM can use fewer instances, those with more RAM, more instances.
    Get away with any such restriction.

    And of course, also drop the fact that this small part of memory needs to be shared by multiple instances of the same AU.

    You can run 10 different Pianos Apps at once, but if you prever one of them, you can only run 1 instance?
    That's an idea out of the asylum!

    Apple is insane about controlling things - even if this control is useless.

  • tjatja
    edited February 2019

    Ah, and most devices have 2GB now and for the newer, it is even more: 3 or 4 GB
    The biggest iPad has 6 GB

  • @tja said:
    Ah, and most devices have 2GB now and for the newer, it is even more: 3 or 4 GB
    The biggest iPad has 6 GB

    Thanks.

    Here's the next issue with realtime processing. Adding more RAM can move the resource
    problem to the CPU specifically to move blocks of audio around and processes them in parallel. Miss the timing on processing a block and you get crackling in the audio out stream.

    Apple is trying to provide a realtime platform with predictable performance using rather limited hardware because they don't have fans on these CPUs to reduce the heat a desktop might generate with 16 Cores all cranking in parallel.

    Being mad at Apple shows a lack of understanding of distributed systems. Shit doesn't fail because of "rules" it fails because we push beyond the boundries of the platform.

    TRY THIS: run your workload on an Android system. Apple smokes that platform with a better realtime OS. If music is not a game to you buy the right tool for the job and stop thinking someone is holding you back. It's just not true.

    Desktops do not have these problems. They are designed with CPU's, Busses, caching memory tiers with 128GB of RAM hardware to keep data pipelines full of data and parallel I/O with really fast and very large SSD's for storage. Fully built-out they cost $5,000. One gets what one pays for. Engineering is a science and sound engineering requires understanding the art and science of music and the hardware used to make it.

    Analogies are intended to open your mind to the complexity you don't really comprehend and help you re-think where the problem might be. It's not Apple's rules. They change the rules as the hardware progresses with 6GB on the top end and 2GB on the cheap device.

    I'm sorry for your frustrations but you expect too much from a tablet and Apple frankly just tunes you out and keeps working on the next set of features to implement, document and train developers on. It's working pretty well but still there are limits. Engineer accordingly in line with the results you can hear.

  • I think I need to unwrap the analogy to help folks understand what the results are if AUv3'are allowed unlimited memory.

    Here's the table of iPad Tech versus House Power Systems:

    House Power Box (managing the circuits - 15 Amp or 30 Amp with 1,2,3 Phases)
    Is like the IOS (Apples's Operating System product)

    Power Strips are like DAW's in that they provide some number of 110v ports
    plugging Power Strips into Power Strips is almost a feature of something like AUM/AB3

    Here! Add enough AUv3 until you throw the circuit... then drop one and you're good to go.

    Appliances (devices generating load on the circuits) are the AUv3s

    CAUTIONS:
    Hack the power box and you can provide enough current to melt the house wires and you will start a fire. Apple doesn't really control the current. They just test AUv3's to see if they use more than the current suggested in their standards to avoid fires.

    House Fires are not recommended. Big appliances that draw a lot of current get 30 Amp circuits with wires than can take the high load appliance. A Clothes Dryer for example gets 30 Amp circuit. Colussus Piano is a Clothes Dryer. It throws the circuit on all my DAW's. I run it on an iPhone and into an audio interface to the iPad to record mine.

    So, what is an iPad Fire? It's when the music becomes a loud grating sound of a failed App. You're heard it. Its a total failure of the sound output signal. Annoying. Yes. But imagine if that failing DAW is connected to a stage PA driving 20,000 Watts of power for a rave audience. Some one is going to get sued for the psychological damage inflicted on the dancers. It should be avoided at all costs says Apples Lawyers or we should be able to point to the culprit.

    So, court damages look for the culprit if an iPad Rave goes into the danger zone.

    Apple asks all DAW's to terminate AUv3 for Apps that exceed the RAM requirements and avoid meltdowns of the audio chain. Apple is free and clear.

    The DAW shows they avoid giving any AUv3 plug-in too much resource and manage the system to prevent failures. The DAW is free and clear.

    The AUv3 grabs a lot of RAM and usually gets terminated when too many notes are played or 2 or more copies are loaded up to the DAW. So the AUv3 is free and clear.

    There's NO CULPRIT. Wait. There was a DJ.

    But the DJ hates limits on creativity and fires up some background standalones with the DAW. Mayhem ensues and the DJ is charged with assault.

    You are the DJ. Be a professional and learn your tools and what they can and cannot do.
    Don't ask Apple to allow noise fires and get angry when the just ignore some random idiot without a clue. I'm not calling you an idiot. We are all stupid about something or many things in my case. But when you know something you should slip the newbie a clue.

    Stay out of trouble.

    Here's another type of house fire. Turn your iPad Volume up to the max and open an ApeFilter FX AU and test all the presets with a loud synth. You''ll damage your ears and loose hearing. Is ApeFilter responsible to you for this outcome? Should they not process the settings of the preset because they detect extreme volumes at some killer frequencies?

    Many would say yes. ApeFilter should NEVER cause hearing loss. Apple's free and clear so there's no regulations for AUv3s that push maximum volumes to the output.

    So stripped of analogies be careful what you expect Apple to allow us to do to ourselves and to others with sound. Make safe music.

  • man i do not get it, it seems to be working today after rebooting my ipad. love that piano

  • @eross said:
    man i do not get it, it seems to be working today after rebooting my ipad. love that piano

    ha. reboot. Working solutionsion for IT issues since stone age. Was probably working even on abacus :lol:

  • @McD I don't get your arguments. And I am too much frustrated to continue discussing.

  • @tja said:
    It kind of totally nullyfies the purpose of AU :| :| :|

    Not really, because 99% of all AUs don't need such ridiculous amounts of RAM. In fact, I think that with most AUs out there you can load more instances than your CPU can handle in the first place.

    Also multi-instance is hardly the only advantage of using AUs. I'd argue that having effortless state-saving is an even more important aspect of AU.

  • @brambos said:

    @tja said:
    It kind of totally nullyfies the purpose of AU :| :| :|

    Not really, because 99% of all AUs don't need such ridiculous amounts of RAM. In fact, I think that with most AUs out there you can load more instances than your CPU can handle in the first place.

    Also multi-instance is hardly the only advantage of using AUs. I'd argue that having effortless state-saving is an even more important aspect of AU.

    Of course I meant those AU which do need lots of memory, as with Ravenscroft and other Samplers.

    I'm not such an fan of AU so far.

    But as I said, even if there would be a reason to limit an instance of an AU, I cannot see any reason at all to limit all instances of an AU to the same amount of memory!

    It just means you would need to use different Apps even if you would like to use only one.
    Just because in this case you get multiple times this amount of memory.

    Instead of using 3 instances of Ravenscroft, you would need to use this and 2 other Piano Apps.
    I think that this is incredible stupid from Apple.

  • @tja said:
    Instead of using 3 instances of Ravenscroft, you would need to use this and 2 other Piano Apps.
    I think that this is incredible stupid from Apple.

    You can't run 3 instances of Ravenscroft under any circumstances. It does disk streaming of a piano model that's 1GB in size using some clever programming tricks it runs in an single AU instance. You might load 2 but give them MIDI files to render and watch out. The RAM isn't the issue it's CPU multiprocessing that starts to fail to feed audio to the output. Loading Ravenscroft and BS-16i Salamander will probably show you the proof that simply changing the "15 Amp Rule" will still break the platform for resources to delivery realtime piano sounds. You'll get audio "fires". They are very bad for recording and live music. In fact they ruin your work. So, Apple isn't stupid with RAM guidelines. They are applying engineering disciplines to the platform for users to benefit from a well designed system. Consider using multiple iPad's/iPhones for extremely complex uses of large sample Apps/AUs. Be the engineer that solves problems and not the user that complains without looking for root causes. The root cause if the software on the iPad running without delays cause the output buffer to miss a scheduled transfer of the next few milli-seconds of realtime sound.

    You know when your YouTube Video stream stalls. This approach to audio prevents stalls in audio streaming. It's not the Apple guideline to make an AUv3 a good actor in a multi-AU DAW. I think Colossus grabs ore the 340MB and the DAW's just terminate it. I use it as an IAA app but it causes "fires" in the output since there's nothing preventing it from consuming too much CPU and RAM bandwidth and making the DAW become the bottleneck and producing audio defects.

    Try iSymphonic and RC275 or any combo of high resource sample based apps and I bet you can break your DAW easily.

    I'm thinking about getting an iConnect4+ to run 2-3 IOS devices loaded with these types of apps. I'm sure the problem will just move to USB bandwidth or delays to make a new series of headaches. If I really need complexity I'll move to a Mac and get it done. But I prefer no cables and a mobile platform. I strap an iPhone to my guitar with velcro and using headphones and an iRig interface I can take a walk and practice for an hour or more with a USB battery pack. I can't do that with any other platform (Mac or Android) that runs something like ToneStack or AUM loaded with FX. Apple is not the villain here.
    They are the leader.

  • @McD As I said, I totally don't get you.

    What I wrote, is about Apples ideas not only to limit one App to a certain memory size, but even all of it's instances.

    This is a generic complain and has nothing to do with Ravenscroft.
    It also has nothing to do with Apps that require a lot of CPU.
    You need more CPU? Get a stronger device. Easy.

    I try again:

    1) It is totally stupid to limit any AU App to any memory at all.
    If you don't have enough memory, you just don't have enough memory.
    This works perfectly for all other operating systems.

    Have a look at any game for Windows, it exactly lists what it needs. You don't have that, don't use it or buy more RAM.

    This would also work perfectly for iOS, if not Apple limited the usage of RAM.
    Very bad.

    2) Even if there would be any reason limit AU Apps to some amount of memory, there sure is no reason to limit all of the instances to that same amount, not multiplied.

    This is stupid, as it has no effect at all, beside being forced to use different Apps with only one instance each.
    This is useless and just hinders people to do what they want.

    Why force people to use App 1, App 2, App 3, App 4,... instead of just using 4 instances of App 1?

    Maybe I just can't get my point over, not being fluent in English.

  • Without such memory limitations, you could use any App you want, until it eats too much CPU.

    And you could run as much instances of an App as possible within the RAM your device has, of course again until you hit a CPU limitation.

    As for any other operating system.

  • I found a comparison that may help:

    Imagine, Microsoft would limit the amount of RAM available to word processing Apps, like Microsoft Office Word or OpenOffice Word.

    Having a limitation would mean that you can only open one document in Word, even when you have lots of RAM free!

    If you needed to open a second document, to compare them, you would be forced to open the second in OpenOffice instead. As you cannot open a second document in Word because of the limitation.

    That's stupid ;-)

  • McDMcD
    edited February 2019

    Word processing is not a real-time process. So why doesn’t surface offer you what you seek. If it does then show Apple some competition.

    Trade offs are needed to make multivendor real-time stable.

    Here’s my analogy. You can buy a gun load a bullet and point it at your face and pull the trigger. That’s freedom. Apple wants to slip the bullet vendor a clue about misuse of this feature. Use IAA or ask the DAW vendor to push to ignore the constraint. Apple might reject the update but they have a reason.

    Apple is Walmart and they get sued for selling the gun and bullets.

  • McDMcD
    edited February 2019

    Ramens Croft should you multiple version with different names that all sound ifentical then you’d just get a refund and give up.

    I hate my iPhone RS for text. Damn you Apple and my failing eyesight.

  • OK, obvious we both don't have an idea why Apple did this.

    You say, they have a reason.
    I say, they are simply over-regulating as always.

    Nothing more to discuss, OK?
    :)

  • tjatja
    edited February 2019

    @McD said:
    I hate my iPhone RS for text. Damn you Apple and my failing eyesight.

    Hehe, I know this.
    I use SwiftKey to better things, but that sometimes totally fails too.

  • @tja said:
    OK, obvious we both don't have an idea why Apple did this.

    You say, they have a reason.
    I say, they are simply over-regulating as always.

    Nothing more to discuss, OK?
    :)

    I do thing it's obvious why they regulate the size of AUv3 given the products they still need to run on. I have seen folks saying they have AUM setups with 20 AU's. Imagine that. If a single AU could consume more RAM then fewer AU's would run t the same time.
    Tradeoffs. No matter what the "rules" are the system supports what it can until it can't.

    So, we freeze tracks. Changing Buffer settings. etc. Trial and Error. Let's go another few rounds slinging epithets at UVI for making crappy apps like BeatHawk and RC275 but never look in the mirror. Have you noticed Apps creeping up in resource uses to delight us: Aparillo, Turnado, etc.

  • I do know that i’ve Got 30 Obsidians going no problem. MEMORY AND CPU YOU ARE NOT THE BOSS OF ME!!

    :trollface:

Sign In or Register to comment.