What about this workaround... but first, i have 2 assumptions - i'm not sure if it is possible and if it works THIS way, so if my assumptions are wrong, my idea is no-go ..
assumption1: AUv3 plugin is able act as AU host, so you can load other AUv3 plugin from plugin itself.
assumption2: AU parameters are simply MIDI CC, just taged with nice name
Now, my idea:
in Odessa will be select "get CC names from plugin parameters"
using this select, user chooses AU plugin
you load plugin on the background (without need of displaying it's UI), read AU parameters map, then you can upload plugin
you use nice names for AU plugin parameters (until users loads different map or reset it to default CC numbers)"
Looks killer. Great job! I'd really like to see Intua add the rumoured 'AU param modulations' so a lot of this stuff could be done via BM3. But long term this AU midi development looks really interesting in terms of other functionality and different AU being able to link together like modular. Interesting times ahead....
They don't really have a choice but to implement AU MIDI, Intua are pretty much at the forefront of audio tech on IOS right now, i suspect they will be the next to implement it (Complete guess by the way, no info at all on this)
They can't really afford to ignore stuff like AU MIDI when other developers are looking for a one up on BM3 at the moment.
Pre pad AU MIDI slots (Notice plural, you want AU MIDI to be able to feed AU MIDI in a chain like audio FX now) are the way forward for sure, it needs to be pre pad rather than just pre AUi because obviously you want this stuff working with the sampler too
The only 'problem' with AU Midi for now is that the AU Plug-Ins have no way to exchange information between each other. Meaning you can not directly select another plug-ins AUParameter in the Odessa Plug-In.
So in the case of Odessa it sends 'midi' to the host(AUM in this case) and the host has to map the midi to the destination plug-in using it's AUParameter names...
@Nick he doesn't mean MIDI thru, but direct parameter attach, which can't be done on the desktop either, passing VST automation between plugins has long been a pain in the jacksy.
So the AU MIDI plugin has to generate MIDI, then the AUfx/i plugin has to be configured to use that MIDI on a specific parameter, because the AU MIDI plugin isn't hosting the AUfx/i plugin it can't see that plugins parameters direct.
The host could store them in an array to be read by AU MIDI plugins, but much like the desktop, this would not be part of the plugin standard (AUv3) and doubtful any host developer is going to jump on a non standard.
Wow. I hear you. I just meant thru as as an analogy... I would have assumed that a standard midi port and channel addressing standard would have been in place, or at least abstracted, with interpretation of midi endpoints being done internally by the receiving instrument without explicit parameter calls or bindings on the iOS API level. Sender sends, receiver receives, byte stream used, a sysex analog or custom 14-bit message being used to address certain parameters.... I am glad I never bought into iOS development. Ouch. That sounds mad!
AU/VST Automation is not MIDI, so it isn't as simple as MIDI sender/reciever.
It is just event data at whatever resolution the host chooses, there is a theoretical limit in each standard, but on the desktop a bunch of developers ignored that and also implemented aliasing too for parameter smoothing.
You're right. I was focusing on the midi standard, not the API standards that wrap the host/client. Aliasing. I couldn't find a puke emotion. Yuck. A standard is screwed when you have to wriggle functionality into it, then once that crack is open... it becomes a 'standard' approach of its own. My respect for the team here has grown.
To be fair, VST only grew in to the almighty it is now because most of the developers extended it on their own and ignored the standards.
That will never happen on IOS because of Apples death grip, so you will probably never get an AUv3 that just loads AUv3s, which is a shame, just one example.
NKS blows goats, its based on a closed system for one, add to that the separation of NKS vs user content, meaning basically you always end up with two browsers, add to that the fact that a user can't create NKS version of their own damn content, in fact the 3rd party suppliers who have been making NIs content delivery systems worthwhile, albeit not paying NI a licence to encrypt, can't even make NKS versions, you have to ask yourself WTF is the point here.
Standards only work when you let them fly, as soon as you try to close them in any way, you kill them, simple as that, there is a reason that VST is the most widely support plugin platform that ever existed.
NKS in a nutshell...
1 You can only use it if you jump through legal hoops.
2 If you wish to support us by supplying content for our customers on our platform, you must pay us and be encrypted, then and only then can you use NKS.
Right now i have a stick up my jack about NI, they have really annoyed me with the current round of lies that went with the release of the MK3, I am seriously considering selling all my NI gear.
Love it! Ha ha ha. Similar sentiments about Not Interested myself these days! Do not like closed “ecosystems” and formats. I’ve often wondered about ditching Apple too, but again, not the place for that noise here. Renoise and Reaper are Linux friendly. VST is a bit of a hassle there (but I’m coming at it from old skool too - should check it out, may have improved), but if the funds are available, stand-alone hardware is viable with Linux, and so are better standards. Shame about the GUI issues, but again, putting a lid on it here. Convenience is the battle for me - always on the move, mac book for coding, ipad for music. Handy. Apps are affordable, but this “no brainier” crap speaks volumes. Better go. Peace.
Linux has come on leaps n bounds with the Linux build of Reaper, if Toneboosters was on Linux i would consider swapping over now.
Apple are currently the worst computer systems on the planet except for mobile, an eight grand Imac that will be out of date in two years, utter and complete nonsense !!!
I was already using Ruismakers euclidean sequencer for sick Amen chops, but that was the standaplone, I dont yse AUM so hoping that Intua implement this soon.
Was speaking with Bram earlier about BM3 and other Daw’s putting this app on another level - in a direct way. (although I Love AUM), he is also excited about the idea @mathieugarcia.
Once again I have every confidence and forever optimistic .. “it’s my nature”.
Yeah, hoping BM3 gets the AUv3 midi stuff added soon, as well as more midi functionality! But thankfully this works through AUM, for those of us who have AUM. I admit I rarely even used AUM before today. I never took the time to learn how to use it, but I liked the idea and wanted to support the dev
Edit: also, I saw you mention ruisemaker triggering amen chops a couple weeks ago, which prompted me to get ruisemaker myself
Interested to see this AUv3 midi play out and see how it feels to set it up and use it. Hoping it's not a typical BM3 'view switching' orgy and that it's not another thing where intua are kinda jumping over putting the basics in place first, like adding their own arpeggiator etc to the keys/pads views.. Which would obvs be super fluid workflow to use/setup if internal and intua could keep it solid without fear of 3rd party updates (minus apple) screwing things up etc..
No denying that long term the AUv3 midi will be amazing for combining some weird stuff together. But it feels like possibly over zealous FR prioritising again to me and also requires people buy other apps just to get a decent basic arpeggiator which should be onboard already imho.... Guess we'll see...
@Heyez adding AUv3 MIDI was super straightforward. Anyway, we have the arpeggiator in the TODO list for a while now, this is one missing block for sure. It's definitely coming!
Cool Sounds like a great quick-fix workaround then until the heavier coding for internal arpeggiator can get looked at Excited to experiment with some of the weirder arp/sequencer apps out there Nice work!
Implementing the arpeggiator within BM3 is a bit more involved, and related to a couple of improvements as well so it will take a bit more time to roll out. AUv3 MIDI out fills the gap in the meantime!
Cheers!
Yup, very cool to have the AUv3 option there in the meantime
Wondering now if there are any AUv3 midi step sequencer apps out there that have parameter step locks and could be used in place of the BM3 sequencer if someone wanted to get an elektron sequencer kind of thing set up on certain pads?
Could also provide a workaround for the current limitation with scene mode not recording to midi. If there's an AUv3 midi app that has similar functionality to the BM3 scene mode.
My knowledge/understanding of midi in general is pretty limited and especially in terms of ios. But guessing a midi AUv3 sequencer on one pad can automate cc for another pad and shouldn't be too hard to set up?
Will be interesting to have all kinds of different sequencers available as an option in addition to/instead of using the main BM3 sequencer
@StudioES yeah looks like it'll open things up and offer infinite options
I was never against adding it at some point. My only concern was about the dev timeline and that in other daws/sequencers a lot of the arp/sequencer trickery that this AU Midi will get used for, is available internally without page/view hopping etc. And that makes a huge difference to workflow when experimenting while setting things up and also when performing.
Was just voicing concern that I hoped that a ton of time wasn't given to this as priority over expanding the internal BM3 sequencers/arp functionality so that it rivals those other apps sequencing/arp stuff all by itself with a tidier workflow than using AUv3 midi
Sounds like it was a super fast thing to add tho and is totally win/win for everyone, and will be fun to use some less traditional sequencers inside BM3. Good times
By the way; although I do have some things on the roadmap already I’m always open to suggestions for other plugins that could augment BM3’s native functionality
Comments
"@brambos said:
I have room for a few beta testers. Let me know if you'd like to help me squash out the last few bugs.
Odessa requires access to iOS11 and AUM (currently the only host which allows AUv3 MIDI routing)."
"@brambos:
What about this workaround... but first, i have 2 assumptions - i'm not sure if it is possible and if it works THIS way, so if my assumptions are wrong, my idea is no-go ..
assumption1: AUv3 plugin is able act as AU host, so you can load other AUv3 plugin from plugin itself.
assumption2: AU parameters are simply MIDI CC, just taged with nice name
Now, my idea:
in Odessa will be select "get CC names from plugin parameters"
using this select, user chooses AU plugin
you load plugin on the background (without need of displaying it's UI), read AU parameters map, then you can upload plugin
you use nice names for AU plugin parameters (until users loads different map or reset it to default CC numbers)"
https://forum.audiob.us/discussion/21905/odessa-coming-very-soon/p10
This is gonna be awesome. Excited about the LFOs
They don't really have a choice but to implement AU MIDI, Intua are pretty much at the forefront of audio tech on IOS right now, i suspect they will be the next to implement it (Complete guess by the way, no info at all on this)
They can't really afford to ignore stuff like AU MIDI when other developers are looking for a one up on BM3 at the moment.
Pre pad AU MIDI slots (Notice plural, you want AU MIDI to be able to feed AU MIDI in a chain like audio FX now) are the way forward for sure, it needs to be pre pad rather than just pre AUi because obviously you want this stuff working with the sampler too
The only 'problem' with AU Midi for now is that the AU Plug-Ins have no way to exchange information between each other. Meaning you can not directly select another plug-ins AUParameter in the Odessa Plug-In.
So in the case of Odessa it sends 'midi' to the host(AUM in this case) and the host has to map the midi to the destination plug-in using it's AUParameter names...
No MIDI thru, emulated or otherwise? Why has MIDI been so patchy on iOS? I would have thought that it would have ironed out at this stage...
@Nick he doesn't mean MIDI thru, but direct parameter attach, which can't be done on the desktop either, passing VST automation between plugins has long been a pain in the jacksy.
So the AU MIDI plugin has to generate MIDI, then the AUfx/i plugin has to be configured to use that MIDI on a specific parameter, because the AU MIDI plugin isn't hosting the AUfx/i plugin it can't see that plugins parameters direct.
The host could store them in an array to be read by AU MIDI plugins, but much like the desktop, this would not be part of the plugin standard (AUv3) and doubtful any host developer is going to jump on a non standard.
Wow. I hear you. I just meant thru as as an analogy... I would have assumed that a standard midi port and channel addressing standard would have been in place, or at least abstracted, with interpretation of midi endpoints being done internally by the receiving instrument without explicit parameter calls or bindings on the iOS API level. Sender sends, receiver receives, byte stream used, a sysex analog or custom 14-bit message being used to address certain parameters.... I am glad I never bought into iOS development. Ouch. That sounds mad!
AU/VST Automation is not MIDI, so it isn't as simple as MIDI sender/reciever.
It is just event data at whatever resolution the host chooses, there is a theoretical limit in each standard, but on the desktop a bunch of developers ignored that and also implemented aliasing too for parameter smoothing.
You're right. I was focusing on the midi standard, not the API standards that wrap the host/client. Aliasing. I couldn't find a puke emotion. Yuck. A standard is screwed when you have to wriggle functionality into it, then once that crack is open... it becomes a 'standard' approach of its own. My respect for the team here has grown.
To be fair, VST only grew in to the almighty it is now because most of the developers extended it on their own and ignored the standards.
That will never happen on IOS because of Apples death grip, so you will probably never get an AUv3 that just loads AUv3s, which is a shame, just one example.
NKS blows goats, its based on a closed system for one, add to that the separation of NKS vs user content, meaning basically you always end up with two browsers, add to that the fact that a user can't create NKS version of their own damn content, in fact the 3rd party suppliers who have been making NIs content delivery systems worthwhile, albeit not paying NI a licence to encrypt, can't even make NKS versions, you have to ask yourself WTF is the point here.
Standards only work when you let them fly, as soon as you try to close them in any way, you kill them, simple as that, there is a reason that VST is the most widely support plugin platform that ever existed.
NKS in a nutshell...
1 You can only use it if you jump through legal hoops.
2 If you wish to support us by supplying content for our customers on our platform, you must pay us and be encrypted, then and only then can you use NKS.
Right now i have a stick up my jack about NI, they have really annoyed me with the current round of lies that went with the release of the MK3, I am seriously considering selling all my NI gear.
Love it! Ha ha ha. Similar sentiments about Not Interested myself these days! Do not like closed “ecosystems” and formats. I’ve often wondered about ditching Apple too, but again, not the place for that noise here. Renoise and Reaper are Linux friendly. VST is a bit of a hassle there (but I’m coming at it from old skool too - should check it out, may have improved), but if the funds are available, stand-alone hardware is viable with Linux, and so are better standards. Shame about the GUI issues, but again, putting a lid on it here. Convenience is the battle for me - always on the move, mac book for coding, ipad for music. Handy. Apps are affordable, but this “no brainier” crap speaks volumes. Better go. Peace.
Apple are currently the worst computer systems on the planet except for mobile, an eight grand Imac that will be out of date in two years, utter and complete nonsense !!!
Y'all.
I was already using Ruismakers euclidean sequencer for sick Amen chops, but that was the standaplone, I dont yse AUM so hoping that Intua implement this soon.
Was speaking with Bram earlier about BM3 and other Daw’s putting this app on another level - in a direct way. (although I Love AUM), he is also excited about the idea @mathieugarcia.
Once again I have every confidence and forever optimistic .. “it’s my nature”.
King
..
Yeah, hoping BM3 gets the AUv3 midi stuff added soon, as well as more midi functionality! But thankfully this works through AUM, for those of us who have AUM. I admit I rarely even used AUM before today. I never took the time to learn how to use it, but I liked the idea and wanted to support the dev
Edit: also, I saw you mention ruisemaker triggering amen chops a couple weeks ago, which prompted me to get ruisemaker myself
Nice!
No denying that long term the AUv3 midi will be amazing for combining some weird stuff together. But it feels like possibly over zealous FR prioritising again to me and also requires people buy other apps just to get a decent basic arpeggiator which should be onboard already imho.... Guess we'll see...
@Heyez adding AUv3 MIDI was super straightforward. Anyway, we have the arpeggiator in the TODO list for a while now, this is one missing block for sure. It's definitely coming!
Implementing the arpeggiator within BM3 is a bit more involved, and related to a couple of improvements as well so it will take a bit more time to roll out. AUv3 MIDI out fills the gap in the meantime!
Cheers!
Wondering now if there are any AUv3 midi step sequencer apps out there that have parameter step locks and could be used in place of the BM3 sequencer if someone wanted to get an elektron sequencer kind of thing set up on certain pads?
Could also provide a workaround for the current limitation with scene mode not recording to midi. If there's an AUv3 midi app that has similar functionality to the BM3 scene mode.
My knowledge/understanding of midi in general is pretty limited and especially in terms of ios. But guessing a midi AUv3 sequencer on one pad can automate cc for another pad and shouldn't be too hard to set up?
Will be interesting to have all kinds of different sequencers available as an option in addition to/instead of using the main BM3 sequencer
I was never against adding it at some point. My only concern was about the dev timeline and that in other daws/sequencers a lot of the arp/sequencer trickery that this AU Midi will get used for, is available internally without page/view hopping etc. And that makes a huge difference to workflow when experimenting while setting things up and also when performing.
Was just voicing concern that I hoped that a ton of time wasn't given to this as priority over expanding the internal BM3 sequencers/arp functionality so that it rivals those other apps sequencing/arp stuff all by itself with a tidier workflow than using AUv3 midi
Sounds like it was a super fast thing to add tho and is totally win/win for everyone, and will be fun to use some less traditional sequencers inside BM3. Good times
By the way; although I do have some things on the roadmap already I’m always open to suggestions for other plugins that could augment BM3’s native functionality