Rosetta in AUM fx slot?

(Apologies if this has been covered.. I did a quick search and didn't find what I was looking for.)

I'm just wondering what the deal is with midi effects in Auv3. I guess I'm a little obsessive compulsive with organization, but I find that projects get really cluttered when I have a few rosetta controllers all on their own channel (especially on the phone version). Couldn't they be run in an effect slot as with Envolver?

Comments

  • wimwim
    edited May 2018

    Envolver is being affected by the audio passing through it. Rozeta isn’t affected by audio at all so conceptually it doesn’t make as much sense.

    Also, let’s say the app you have in the input outputs midi. There could be confusion between its output and that of Rozeta. And Rozeta could be affected by it as well. That could go bad real fast.

  • wimwim
    edited May 2018

    Still it would be nice to not have to eat up a channel for each Rozeta instance. That does get confusing fast. So if there is a way to streamline it I’d be all for it.

  • There was discussion about track groups and folders to organize and hide tracks in Cubasis. Something like grouped tracks in AUM that you switch views on would be really cool. Right now I use visual/spatial grouping and the view bookmarks to try to achieve the same thing.
    By visual/spatial grouping, I mean I rearrange my tracks so they are in groups from left to right, separated by bookmarks. I only do this when I get too much stuff going at once though.

  • edited May 2018

    It's because iOS hasn't made a clear way of categorising a midi effect yet. I read briefly on a dev forum post that Apple haven't officially supported pure midi AUv3 plugins yet. They are being slow. so I think current midi effects are still basically instruments which send/receive midi so they have to go in the same slot as the instruments for now...

    Eventually when Apple get their act together the devs can update with more confidence. :)
    So basically Jonatan could spend ages working on a workaround in AUM and then Apple decide to change it.

  • @Carnbot said:
    It's because iOS hasn't made a clear way of categorising a midi effect yet. I read briefly on a dev forum post that Apple haven't officially supported pure midi AUv3 plugins yet. They are being slow. so I think current midi effects are still basically instruments which send/receive midi so they have to go in the same slot as the instruments for now...

    Eventually when Apple get their act together the devs can update with more confidence. :)
    So basically Jonatan could spend ages working on a workaround in AUM and then Apple decide to change it.

    Pretty much this. To give you an idea about the current official state of AU MIDI, here's a screenshot of Apple's documentation for the most important part of the standard:

    All we have now, we have deduced from a presentation slide from WWDC'17 and by reverse engineering Apple's framework headers (and lots of constructive dicussions between ourselves). Needless to say, a lot of it is (to date) left up to us to figure out, including the conceptual philosophy of how to deal with the standard... :#

  • I agree it makes no sense to use a whole audio channel just to host MIDI plugins. I'm meaning to add special "MIDI node slots" in AUM, which can be stacked vertically in a scrollable area - visually a lot like the FX chain in an audio channel right now.

  • WWDC'18 is not that far off so maybe we'll see something then?

  • @Samu said:
    WWDC'18 is not that far off so maybe we'll see something then?

    Another slide? :D

  • @brambos said:

    @Samu said:
    WWDC'18 is not that far off so maybe we'll see something then?

    Another slide? :D

    Hopefully a LOT more :)

    Personal wish list would include improved AUv3 preset handling. It's time to give all AUv3 plug-ins Read/Write access to a common location similar to ~/Library/Audio/Presets/AppName/ which is available on macOS.

    Another is direct access to USB-Attached (using Apples very own CCK) mass-storage devices using Files.app/DocumentPicker.
    (I mean why should I have to use a computer to dump over files from my Zoom H1 to my iPad or iPhone?).

    It makes me sad when some people consider 'emojis' and 'animated imessage crap' to be a solid reason for major iOS update...

    And well since Apple is 'anti 3.5mm jack' they should step up the game and include next to latency-free wireless audio and include the adapters for free or bring back the 3.5mm jack. Focusing on minimising the latency for AirPlay 2 and making it bi-directional could be a start... (Using BT for both audio and midi at the same time equals glitch hell).

  • @Samu said:

    @brambos said:

    @Samu said:
    WWDC'18 is not that far off so maybe we'll see something then?

    Another slide? :D

    Hopefully a LOT more :)

    Personal wish list would include improved AUv3 preset handling. It's time to give all AUv3 plug-ins Read/Write access to a common location similar to ~/Library/Audio/Presets/AppName/ which is available on macOS.

    Yes on all things, but mostly this. Actually I feel they should introduce a generic centralized/shared storage space. The time has come for it. They could still keep apps and their built-in content inside a sandbox, but keeping user files locked away in there has become a bit silly now that everything can be accessed through the Files app. If the Files app is safe enough for them, then a centralized storage area should be too... :)

  • @brambos said:

    @Samu said:

    @brambos said:

    @Samu said:
    WWDC'18 is not that far off so maybe we'll see something then?

    Another slide? :D

    Hopefully a LOT more :)

    Personal wish list would include improved AUv3 preset handling. It's time to give all AUv3 plug-ins Read/Write access to a common location similar to ~/Library/Audio/Presets/AppName/ which is available on macOS.

    Yes on all things, but mostly this. Actually I feel they should introduce a generic centralized/shared storage space. The time has come for it. They could still keep apps and their built-in content inside a sandbox, but keeping user files locked away in there has become a bit silly now that everything can be accessed through the Files app. If the Files app is safe enough for them, then a centralized storage area should be too... :)

    But why would an AUv3 plugin need read/write access to another AUv3 plugins presets?

    If preset handling is supposed to be solved by each plugin, then they can already store their presets in their own Documents folder, making it available at all times regardless of which host they are in.

    However, if preset handling is supposed to be handled by the host, then indeed it would be nice with a global location that can be shared among hosts.

  • edited May 2018

    @j_liljedahl said:

    @brambos said:

    @Samu said:

    @brambos said:

    @Samu said:
    WWDC'18 is not that far off so maybe we'll see something then?

    Another slide? :D

    Hopefully a LOT more :)

    Personal wish list would include improved AUv3 preset handling. It's time to give all AUv3 plug-ins Read/Write access to a common location similar to ~/Library/Audio/Presets/AppName/ which is available on macOS.

    Yes on all things, but mostly this. Actually I feel they should introduce a generic centralized/shared storage space. The time has come for it. They could still keep apps and their built-in content inside a sandbox, but keeping user files locked away in there has become a bit silly now that everything can be accessed through the Files app. If the Files app is safe enough for them, then a centralized storage area should be too... :)

    But why would an AUv3 plugin need read/write access to another AUv3 plugins presets?

    If preset handling is supposed to be solved by each plugin, then they can already store their presets in their own Documents folder, making it available at all times regardless of which host they are in.

    However, if preset handling is supposed to be handled by the host, then indeed it would be nice with a global location that can be shared among hosts.

    Yes, the latter. But a general public file storage would also allow shared access to audio recordings, sample libraries, stems, etc. It would also make it much easier to get samples and other files in and out of AUv3 plugins - which is a royal pain right now.

  • @j_liljedahl said:

    But why would an AUv3 plugin need read/write access to another AUv3 plugins presets?

    Well, one could for example make a 'preset selector' (like some have requested since the dawn of AUv3 on iOS).

    Meaning one could browse thru all the presets from one place (A Plug-In Shell) not caring which plug-in created them and once one selects a preset the proper plug-in would be loaded into the shell with the selected preset.

    That's the 'read' part, 'write' would be needed to 'tag' the presets making it easier to select a preset based on it's tags.

  • @brambos said:

    @j_liljedahl said:

    @brambos said:

    @Samu said:

    @brambos said:

    @Samu said:
    WWDC'18 is not that far off so maybe we'll see something then?

    Another slide? :D

    Hopefully a LOT more :)

    Personal wish list would include improved AUv3 preset handling. It's time to give all AUv3 plug-ins Read/Write access to a common location similar to ~/Library/Audio/Presets/AppName/ which is available on macOS.

    Yes on all things, but mostly this. Actually I feel they should introduce a generic centralized/shared storage space. The time has come for it. They could still keep apps and their built-in content inside a sandbox, but keeping user files locked away in there has become a bit silly now that everything can be accessed through the Files app. If the Files app is safe enough for them, then a centralized storage area should be too... :)

    But why would an AUv3 plugin need read/write access to another AUv3 plugins presets?

    If preset handling is supposed to be solved by each plugin, then they can already store their presets in their own Documents folder, making it available at all times regardless of which host they are in.

    However, if preset handling is supposed to be handled by the host, then indeed it would be nice with a global location that can be shared among hosts.

    Yes, the latter. But a general public file storage would also allow shared access to audio recordings, sample libraries, stems, etc. It would also make it much easier to get samples and other files in and out of AUv3 plugins - which is a royal pain right now.

    Can an AUv3 plugin not use the "new" standard DocumentProvider stuff to import or open external files? (meaning it would show the Files interface in iOS 11). "opening" a file that way, as opposed to "import", allows in-place access to the file with no need to copy it. The access can be stored and reused later via URL Bookmarks.

  • @j_liljedahl said:

    @brambos said:

    @j_liljedahl said:

    @brambos said:

    @Samu said:

    @brambos said:

    @Samu said:
    WWDC'18 is not that far off so maybe we'll see something then?

    Another slide? :D

    Hopefully a LOT more :)

    Personal wish list would include improved AUv3 preset handling. It's time to give all AUv3 plug-ins Read/Write access to a common location similar to ~/Library/Audio/Presets/AppName/ which is available on macOS.

    Yes on all things, but mostly this. Actually I feel they should introduce a generic centralized/shared storage space. The time has come for it. They could still keep apps and their built-in content inside a sandbox, but keeping user files locked away in there has become a bit silly now that everything can be accessed through the Files app. If the Files app is safe enough for them, then a centralized storage area should be too... :)

    But why would an AUv3 plugin need read/write access to another AUv3 plugins presets?

    If preset handling is supposed to be solved by each plugin, then they can already store their presets in their own Documents folder, making it available at all times regardless of which host they are in.

    However, if preset handling is supposed to be handled by the host, then indeed it would be nice with a global location that can be shared among hosts.

    Yes, the latter. But a general public file storage would also allow shared access to audio recordings, sample libraries, stems, etc. It would also make it much easier to get samples and other files in and out of AUv3 plugins - which is a royal pain right now.

    Can an AUv3 plugin not use the "new" standard DocumentProvider stuff to import or open external files?

    I would need to try again. Last time I tried (in the initial release of iOS11.0) it crashed the plugin - at least at that time the only way to get files in/out of an AUv3 was via an AppGroup tunnel to the standalone container of the app.

  • @j_liljedahl said:

    Can an AUv3 plugin not use the "new" standard DocumentProvider stuff to import or open external files? (meaning it would show the Files interface in iOS 11). "opening" a file that way, as opposed to "import", allows in-place access to the file with no need to copy it. The access can be stored and reused later via URL Bookmarks.

    From what I've seen/heard it's a no go at the moment.

    I'm not a programmer but after watching Audiodamage's Quanta demos by Chris Randal it's apparently not possible to use the document browser from within an AUv3 :(

  • @Samu said:

    @j_liljedahl said:

    Can an AUv3 plugin not use the "new" standard DocumentProvider stuff to import or open external files? (meaning it would show the Files interface in iOS 11). "opening" a file that way, as opposed to "import", allows in-place access to the file with no need to copy it. The access can be stored and reused later via URL Bookmarks.

    From what I've seen/heard it's a no go at the moment.

    I'm not a programmer but after watching Audiodamage's Quanta demos by Chris Randal it's apparently not possible to use the document browser from within an AUv3 :(

    Wow, that sucks. So as Bram says, one would need an App Group shared with the container app and put some file management functionality there.

    But I wonder if this is just a bug that could be fixed? I see no logical reason why an AU extension could not use the document browser.

  • @j_liljedahl said:

    But I wonder if this is just a bug that could be fixed? I see no logical reason why an AU extension could not use the document browser.

    I really do hope it's a 'bug' so maybe it will be fixed in iOS11.4 or in worst case iOS12...

    Once AUv3's can properly access the DocumentBrowser/Picker it will most likely make it easier for developers to create 'AUv3 Samplers' with easy file import & export.

    I would for example love to see a way to 'tap-drag-n-drop' stuff from for example the Cubasis time-line or FIles.app to a 3rd party AUv3 sampler or something like that.

  • I’m for anything that makes the backup of my AU presets easier and more uniform across the board. I’ve lost count of the sounds I’ve lost due to badly designed preset management :/

  • edited May 2018

    @j_liljedahl said:

    @Samu said:

    @j_liljedahl said:

    Can an AUv3 plugin not use the "new" standard DocumentProvider stuff to import or open external files? (meaning it would show the Files interface in iOS 11). "opening" a file that way, as opposed to "import", allows in-place access to the file with no need to copy it. The access can be stored and reused later via URL Bookmarks.

    From what I've seen/heard it's a no go at the moment.

    I'm not a programmer but after watching Audiodamage's Quanta demos by Chris Randal it's apparently not possible to use the document browser from within an AUv3 :(

    Wow, that sucks. So as Bram says, one would need an App Group shared with the container app and put some file management functionality there.

    But I wonder if this is just a bug that could be fixed? I see no logical reason why an AU extension could not use the document browser.

    I hope it's a bug but "Open In" dialogs are also not allowed from AU extensions (which would make e.g. exporting presets a lot easier), so it may very well be an intentional limitation :/

    I hope the Files.app inspires Apple to "loosen up" a little bit with regard to sandboxing and related restrictions.

  • Thank you @brambos and @j_liljedahl for sharing your insights about Apple’s poor support of their AU standard. They really seem to be resting on their laurels and investing as little as possible I the infrastructure for iOS music creation. I will register another complaint about these isssues with Apple.

  • @InfoCheck said:
    Thank you @brambos and @j_liljedahl for sharing your insights about Apple’s poor support of their AU standard.

    I'm not even sure whether it's poor support. My guess would be there's a security rationale behind the limitations.
    Either way, would be great if they made it easier to get stuff in/out of AUs because that would make life for the sample-based folks a lot more convenient.

  • @brambos said:

    I hope the Files.app inspires Apple to "loosen up" a little bit with regard to sandboxing and related restrictions.

    Indeed, it would also be super handy to access content mass-storage devices connected using Apples very own CCK-USB dongles instead of having to rely custom solutions where each storage device requires an app.
    (For example load sample directly to an AUv3 from an external storage device like a Zoom H1).

    Sandisk recently added some kind of 'Files.app' support to their iXpand.app but it's very shaky and only shows 'media'(sound, video and pictures) when accessing it from Files.app. The 'other' files are not shown and the separate app needs to be launched in order to access them. Saving any type of files to iXpand drive works though Files.app but you can not 'see' the files in Files.app...

    Well, WWDC'18 is not that far off and I'll be glued to the TV watching most of the sessions.

  • edited May 2018

    Here’s the feedback I gave Apple on their site:

    Apple has failed to adequately support or document their AUV3 standard on iOS. This means widespread inconsistencies with respect to how presets are stored and shared among AU apps and AU host apps which undermines the quality of the user experience. Until Apple provides leadership and guidance for their own standard, developers will be reluctant to support the standard as a significant proportion of their work will become wasted time if Apple should go in a different direction with their AU standard than the developer anticipated. Music creation app developers have been working hard on our behalf while Apple has been sitting on their hands.

    If Apple continues to impede iOS music app development by refusing to invest in basic infrastructure in iOS, I’ll spend my money elsewhere.

    Message Two as I didn’t have enough room in the first message (PID withheld here):

    Last fall I purchased a 12.9” iPad Pro in city, state/province and returned it after a week because its performance with music apps was worse than my iPad Air 2. This was the first time I’d purchased an iOS device where this was the case. The Apple Store employee who was their music expert could not answer any of my questions about iOS music and encouraged me to use Logic on macOS.

    I will not be purchasing a new iOS or macOS device until their is sufficient iOS support so that my user experience will be an upgrade rather than degraded by Apple’s failure to adequately support their infrastructure for iOS music creation app developers who have to scramble to adjust to Apple’s changes and/or Apple introduces standards like AUV3 which are neither sufficiently comprehensive nor adequately documented.

  • @brambos said:

    @InfoCheck said:
    Thank you @brambos and @j_liljedahl for sharing your insights about Apple’s poor support of their AU standard.

    I'm not even sure whether it's poor support. My guess would be there's a security rationale behind the limitations.
    Either way, would be great if they made it easier to get stuff in/out of AUs because that would make life for the sample-based folks a lot more convenient.

    I think your security comment was not directed to me as it seems to target samples for AU apps which wasn’t anything I mentioned.

    By poor support I’m referring to their lack of documentation and not fleshing out the standard for things like AU MIDI only apps and how developers have to be detectives and reverse engineer framework headers or other crumbs dropped by Apple on a slide or in their presentations.

  • Not many people praising the AU workflow on this thread.
    I wonder why?

  • @Samu said:

    @j_liljedahl said:

    But I wonder if this is just a bug that could be fixed? I see no logical reason why an AU extension could not use the document browser.

    I really do hope it's a 'bug' so maybe it will be fixed in iOS11.4 or in worst case iOS12...

    Once AUv3's can properly access the DocumentBrowser/Picker it will most likely make it easier for developers to create 'AUv3 Samplers' with easy file import & export.

    I would for example love to see a way to 'tap-drag-n-drop' stuff from for example the Cubasis time-line or FIles.app to a 3rd party AUv3 sampler or something like that.

    Beathawk AU just updated with icloud drive support so hopefully that'll be more common.

  • @Samu said:

    @brambos said:

    I hope the Files.app inspires Apple to "loosen up" a little bit with regard to sandboxing and related restrictions.

    {snip}

    Sandisk recently added some kind of 'Files.app' support to their iXpand.app but it's very shaky and only shows 'media'(sound, video and pictures) when accessing it from Files.app. The 'other' files are not shown and the separate app needs to be launched in order to access them. Saving any type of files to iXpand drive works though Files.app but you can not 'see' the files in Files.app...

    Just came across this post...

    Are you aware of the FileBrowser for Business app?

    It has iXpand support and pretty good file handling. I don't own an iXpand, but as a long time user of FileBrowser I expect the two should work together perfectly.

    FB also plays nicely with the Files app by the way.

  • @j_liljedahl said:
    I agree it makes no sense to use a whole audio channel just to host MIDI plugins. I'm meaning to add special "MIDI node slots" in AUM, which can be stacked vertically in a scrollable area - visually a lot like the FX chain in an audio channel right now.

    This didn't happen in the latest update right ?

  • @Turntablist said:

    @j_liljedahl said:
    I agree it makes no sense to use a whole audio channel just to host MIDI plugins. I'm meaning to add special "MIDI node slots" in AUM, which can be stacked vertically in a scrollable area - visually a lot like the FX chain in an audio channel right now.

    This didn't happen in the latest update right ?

    It doesn't appear that it did, but I'd be happy to be shown that I'm wrong. :smile:

Sign In or Register to comment.