Best Setup for external app recall?

2»

Comments

  • I see a pattern here related to forum wars.
  • Forum wars ?
    There are some tits over at AB forums, but it is still the number one place for IOS chat.
    KVR is full of tits, still one of the best sites online ;)
  • I don't think the original question has been answered which is loading IAA into AudioBus is the only way they can be state saved. I agree though that the future is now AU. Although I can see the appeal of using apps without a DAW, in the way that you see on a lot of YouTube videos people are using hardware sequencers and synths to create music. In the same way you can do this on iOS - choose your sequencer app, synth apps and connect them together with AudioBus/AUM.

  • Loading an AU is exactly the same as choosing a synth app, just less instability lol
  • @Mark said:
    Although I can see the appeal of using apps without a DAW, in the way that you see on a lot of YouTube videos people are using hardware sequencers and synths to create music. In the same way you can do this on iOS - choose your sequencer app, synth apps and connect them together with AudioBus/AUM.

    But People use hardware sequencers and instruments for a whole other reasons - then just having standalone equipment that is cumbersome to connect to each other. (That's why MIDI was invented in the first place)

    Hardware equipment has totally different Advantages - as it often has better sound and better ergonomics, better haptic feel, more stability (not likely to crash).

    They seldomly choose it just because it's "standalone".
    (well at least other than sequencers with built in sound generators - but even their results have to be transferred to a computer at some Point)

    Now there are A LOT of things worth emulating on computers nowadays - and the touchscreen functionality of tablets gave back at least a little bit of that "hands on" approach in dealing with virtual instruments.

    But there is DEFINITELY one thing that is totally NOT worth emulating - and that is cumbersome connectivity.
    The whole rise and dominance of Pro Tools and digital DAWs in the world of music today is based on convenience.
    Even though economics play also a bit of a role - those technologies mainly where never incorporated by the pros because of money issues - but only because it's more convinient.
    Nobody wants to fuss around with Tape Machines anymore because of the vintage cool factor but also the necessary and tedious tape alligment procedure - when instead you can fire up a full ProTools/Logic/Cubase System with virtually unlimited everything - and record days and weeks of audio material onto hard drives - with FULL and instant recall ability.
    (gone are the days of Studio Equipment Recall Setup Sheets - which is still something you have to deal with, when you use a lot of hardware effects)

    And there is definitely a reasoning and advantage on having an app like audiobus - for chaining instruments and effects and do all crazy experimental stuff - that a full fledged DAW might be to cumbersome for.

    But this not a political thing. It's not either or. It's not REPs vs. DEMs. Us vs. them.

    You can have all of it in ONE app. Supporting standalone as well as IAA and Audiobus and of course ALSO AUv3.
    Nobody has to choose sides here.
    It's just that it seems that the established delevopers and apps - are VERY slow to addopt.
    I think it's partially also because they don't NEED to yet. Nobody is forcing them to add AUv3.
    And because they often already support the other Interfaces, they can always refer to them.
    But from a present DAW point of view - all other Interfaces compared to AUv3 are the least favorable.

  • @william77 said:

    @medaref said:
    No way I’d want to see developers forced to implement AUv3 — or any other technology I don’t need. That’s up to the dev and what they want to offer. Many apps I use and like don’t have it, and they might not exist if they had to please everyone. Nobody’s forced to buy anything that doesn’t match their needs, so read the specs before buying. I thank Apple for this.

    well, you obviously DO "need" AUv3 for any virtual instrument that you want to use in a DAW (like BM3) - and retain 100% session recall abilities and also run multiple instances of one Instrument. And all sorts of other hasslefree stuff.
    (who in their right mind wouldn't want that when using a DAW?)

    And I'm pretty sure that most of the users don't buy Korg, Moog and all the other Synths - just for their great standalone Performance.

    If IAA implementation can achieve that - I don't care. Whatever you call it - just MAKE IT WORK how it's supposed to. I don't give a damn if it's IAA or AUv3. But for the iOS Plattform there is no way around AUv3 - it's Apples brain-child.
    You won't see VST3 coming to iOS and rule the plattform - while AUv3 is treated like a stepchild.

    This kind of implementation by the way is already "standard" in ANY serious DAW on PC/macOS land (like Logic/AU, Cubase/VST, ProTools/AAX, etc.)

    I for one DEFINITELY don't want to have to print every Synth to an audio file - or jot down the preset names and adjustments on paper (old-school hardware style) for a "manual" session recall.
    Because that is sooo kinda 1990ies..

    Because that is why a lot of the iOS Apps do still feel like "toy" stuff - even though the hardware is more capable than that. So much for the "post-PC" era. Big-effin'-LOL....

    Guess what - a lot of the Developers don't like to go the extra-mile for out-of-the-ordinary customer satisfaction. They often just do the needed minimum and cash in - and the customer is then left with a half-baked Beta Software - more or less.

    Let me try to again explain this simply. I don’t need every music app to have AUv3. I’m not asking anyone’s permission to feel that way. There are great apps I use that don’t have AUv3, and even if some would be more convenient as an AU app, they might not exist at all if Apple forced every developer to implement AU, IAA, AudioBus, or anything else. They just have to do what they say they do, and the app can still have value to me and others as a standalone. This includes small devs doing it as a hobby, and larger companies positioning themselves in a market that pays relatively small for sophisticated music apps. If an app doesn’t have AUv3, then you don’t have to buy it. How is it that your preferences are more important than mine?

  • @medaref said:

    How is it that your preferences are more important than mine?

    Well, they aren't - and I never assumed that.
    I'm totally fine with it - if you're not using the plugin portion of an App.

    But where in YOUR workflow would it restrain you - using an App that has additional AUv3 functionality?
    That argument I truely don't understand - because it makes not much sense.

    If a small developer decides to just make a standalone app - with no connectivity options at all - that's something I can live with it.

    But there is no argument to the point that a developer wouldn't even bother to program an App - if he has to incorporate IAA, Audiobus and also AUv3.
    A lot of them already DO support IAA and Audiobus for connectivity - why not support AU for even better connectivity?
    That makes very little sense.

    And to make things really clear - I DON'T BOTHER about John Doe the next door programmer who tinkers around in his free time and makes a "small" music app.
    I'm adressing this towards the big developers like Korg for example. For the amount of money that they are asking for their software - an additional support of AUv3 is totally not a to big of a demand.
    Especially if their addition of IAA and Audiobus indicates the use context of their app - which isn't standalone.

    The only valid argument from a developer point of view is - that refitting existing Apps poses extra risk for introducing extra Problems.
    But a lot of developers refitted their Apps with IAA and Audiobus. So that makes it a moot point.

  • @william77 said:
    The only valid argument from a developer point of view is - that refitting existing Apps poses extra risk for introducing extra Problems.
    But a lot of developers refitted their Apps with IAA and Audiobus. So that makes it a moot point.

    Not exactly. Because IAA and Audiobus only require moderate internal changes. Retrofitting AUv3 means a total overhaul of the app's UI and a complete rebuild of the internal structure. It requires a totally different code architecture. Basically, you have to redo your entire app development process. Considering you can't charge for updates on an app that is already live, I can imagine that's a tough one for small devs (a lot of daunting work) and big devs (a lot of effort for not too much return on investment).

  • @brambos said:

    @william77 said:
    The only valid argument from a developer point of view is - that refitting existing Apps poses extra risk for introducing extra Problems.
    But a lot of developers refitted their Apps with IAA and Audiobus. So that makes it a moot point.

    Not exactly. Because IAA and Audiobus only require moderate internal changes. Retrofitting AUv3 means a total overhaul of the app's UI and a complete rebuild of the internal structure. It requires a totally different code architecture. Basically, you have to redo your entire app development process. Considering you can't charge for updates on an app that is already live, I can imagine that's a tough one for small devs (a lot of daunting work) and big devs (a lot of effort for not too much return on investment).

    Well thanks for the clarification. I can totally understand that. Especially if it's a feature-heavy complex App.

    But how long is AUv3 around now? Did it came after - let's say Korg Arp Odyssei or iWavestation?
    Because these are fairly new Apps and don't support AUv3 at all.

    If so - time will tell if those developers choose to rewrite their Software.
    So I will keep my eyes open on newer Apps like your stuff and the new Kaspar Synth.

  • @william77 said:

    @medaref said:

    How is it that your preferences are more important than mine?

    Well, they aren't - and I never assumed that.
    I'm totally fine with it - if you're not using the plugin portion of an App.

    But where in YOUR workflow would it restrain you - using an App that has additional AUv3 functionality?
    That argument I truely don't understand - because it makes not much sense.

    If a small developer decides to just make a standalone app - with no connectivity options at all - that's something I can live with it.

    But there is no argument to the point that a developer wouldn't even bother to program an App - if he has to incorporate IAA, Audiobus and also AUv3.
    A lot of them already DO support IAA and Audiobus for connectivity - why not support AU for even better connectivity?
    That makes very little sense.

    And to make things really clear - I DON'T BOTHER about John Doe the next door programmer who tinkers around in his free time and makes a "small" music app.
    I'm adressing this towards the big developers like Korg for example. For the amount of money that they are asking for their software - an additional support of AUv3 is totally not a to big of a demand.
    Especially if their addition of IAA and Audiobus indicates the use context of their app - which isn't standalone.

    The only valid argument from a developer point of view is - that refitting existing Apps poses extra risk for introducing extra Problems.
    But a lot of developers refitted their Apps with IAA and Audiobus. So that makes it a moot point.

    I’ve made no argument that AUv3 isn’t desirable. I love having AU apps to plug into hosting apps. The point is about Apple forcing devs to implement it.

    Some very small companies (like one person) make very big iOS apps. An example: I’d still use Auria Pro if the dev didn’t want to include AUv3 hosting. I bought it with no promise that it would have it. How about GeoShred? One of my favorites. Should they be forced in to anything? To redesign their interface for AU? Could be good, but I don’t need it. Gadget is also a favorite of mine. One of the more reliable apps on iOS, and I think it’s a product that sells devices for Apple. I don’t know how vital the music app market is to Apple, but I’m just happy that they’ve been wise enough to let Gadget be Gadget and Korg be Korg. We have options. Let the market decide.

  • @william77 said:

    @brambos said:

    @william77 said:
    The only valid argument from a developer point of view is - that refitting existing Apps poses extra risk for introducing extra Problems.
    But a lot of developers refitted their Apps with IAA and Audiobus. So that makes it a moot point.

    Not exactly. Because IAA and Audiobus only require moderate internal changes. Retrofitting AUv3 means a total overhaul of the app's UI and a complete rebuild of the internal structure. It requires a totally different code architecture. Basically, you have to redo your entire app development process. Considering you can't charge for updates on an app that is already live, I can imagine that's a tough one for small devs (a lot of daunting work) and big devs (a lot of effort for not too much return on investment).

    Well thanks for the clarification. I can totally understand that. Especially if it's a feature-heavy complex App.

    But how long is AUv3 around now? Did it came after - let's say Korg Arp Odyssei or iWavestation?
    Because these are fairly new Apps and don't support AUv3 at all.

    That's right. It makes much more sense to implement AUv3 in new synths from now on. Especially seeing how clumsy (and unreliable) IAA actually is it provides a much better user experience to go the AU route.

    I see merits in Audiobus 3, as it takes away some of the MIDI configuration pains for people who wish to use MIDI apps. Especially now that they also let you host AU plugins: once iOS11 hits and AU plugins are able to send out MIDI, Audiobus 3 could be well-positioned for 'modular' setups where people basically build their own DAW using AU synths and AU-based sequencers. I hope they'll grow in that direction.

    For Korg, I suppose not going AU is a business decision. They want you to be locked into the Gadget environment on iOS to keep you buying the IAP Gadgets.

  • I can see where Korg would want people buying their IAP’s. That makes sense, but only if being a more closed system doesn’t discourage people from buying Gadget to begin with. I’m not a developer, nor do I talk with Korg, but I wonder if their system isn’t designed more for simplicity and reliability. What does Korg think about AU, and would it needlessly complicate their app, and/or cause more problems than they want to be associated with or have to deal with? As it is, they’re in control of the Gadget environment.

  • edited August 2017

    Korg is going to starve their iOS market because of tunnel vision. I am just like many other who make money from music, love the cutting edge of iPad, but need that AU support...we will wait. We know all headaches associated with the other solutions. The customer's money is king, and enough requests and holding out can at least pressure them into communication about it.

    Shoutout to Intua for realizing this support is key to the future of IOS, and for still supporting the other solutions that MAY stick around for a while.

Sign In or Register to comment.