So what's next for U-He?
-
- KVRist
- 212 posts since 26 Nov, 2005 from Maine
Instead of the "everything in a VST" concept I think that given the groundswell of interest in modular, it would be better to add flexibility to the entire U-he family with allowing I/O from any point in the signal path. If you just want to output the LFO from Bazille, and input it to Diva's oscillator.. do it.
If a good route exists to do this using the DAW's routing I would think that is preferred. If that's impossible with today's standards, then is it possible to put a "back channel" in, so that U-He plugins can talk to each other via a private virtual hub?
If a good route exists to do this using the DAW's routing I would think that is preferred. If that's impossible with today's standards, then is it possible to put a "back channel" in, so that U-He plugins can talk to each other via a private virtual hub?
You are not a beautiful snowflake.
- KVRAF
- 23077 posts since 7 Jan, 2009 from Croatia
Yeah stuff like that isn't feasible in all DAWs, because some have more constrained routing options.
-
- KVRAF
- 6444 posts since 17 Dec, 2009
well back-channels independent of DAW's routing are possible with AU and VST3 tho.EvilDragon wrote: ↑Sat Aug 01, 2020 12:22 pm Yeah stuff like that isn't feasible in all DAWs, because some have more constrained routing options.
like iZotope communicates or routes cross-plugin
- u-he
- 28044 posts since 8 Aug, 2002 from Berlin
That is possible easily with monophonic concepts, yet it's next to impossible with voice based polyphonic synths.
Trying to overcome the limitations of plug-in environments in order to achieve this is like opening a box of Pandora which pops out an onslaught of more boxes of Pandora.
Just think about DAWs which are multithreaded (all popular DAWs might be) - there's no guarantee that plug-ins are processed in any kind of order. Each path plug-in to plug-in would need to sport safety buffers and introduce latency. That alone would break it for many purposes. And that's before mentioning sandboxed environments.
Monophonic synths on the other hand could simply have multiple inputs and outputs, which leaves the burden of data management and communication where it belongs: On the host side.
#------
In reply to blue monk et al:
There's a great variety of reasons some synths can't just be made polyphonic. CPU etc. aside, there are many concepts in Synthesis and Musical Performance which are mutually exclusive to the concept of "voices which pop in and out with the notes to play". The 1:1 relation of notes and voices isn't a dogma, it's just the traditionally most popular concept. However, something as simple as the Drone switch on Repro-1 would not work in a polyphonic context, and neither does interoperation of plug-ins. For instance, not many people really want to deal with 16 separate channel strips of individual voice outputs of a polyphonic synth. It's just easier to keep these complex polyphonic concepts enclosed in one unit.
- u-he
- 28044 posts since 8 Aug, 2002 from Berlin
We do so, too. In Satin for instance one can group instances to sync parameter and preset changes.Ploki wrote: ↑Sat Aug 01, 2020 12:45 pmwell back-channels independent of DAW's routing are possible with AU and VST3 tho.EvilDragon wrote: ↑Sat Aug 01, 2020 12:22 pm Yeah stuff like that isn't feasible in all DAWs, because some have more constrained routing options.
like iZotope communicates or routes cross-plugin
I'd be somewhat open to sending MIDI or control signals between instances, too. Just haven't had any need, yet.
But I highly doubt that sending audio for the purpose of interconnecting synthesizer signal paths is feasible.
- u-he
- 28044 posts since 8 Aug, 2002 from Berlin
Sure, but...
I think that question will come up once interfaces, drivers, hosts, plug-in formats start adding support. I don't really want to spend any time on this now in hope that someday it will be useful. We are small enough that we need to double check where we spend our time and which matters need to be attended to more urgently.
- KVRAF
- 23077 posts since 7 Jan, 2009 from Croatia
Well, VST SDK v3.7 added support for MIDI 2.0, at least. I guess Cubase 11 will support it too, purely conjencture but it makes sense.
-
- KVRian
- Topic Starter
- 605 posts since 28 Oct, 2010 from Mexico
Hopefully this will make Ableton finally adopt MPE which is part of the MIDI 2.0 spec. AFAIK it's the only major DAW that does not support it.EvilDragon wrote: ↑Sat Aug 01, 2020 6:05 pm Well, VST SDK v3.7 added support for MIDI 2.0, at least. I guess Cubase 11 will support it too, purely conjencture but it makes sense.
I've always wondered if there are any public stats on DAW market share. From what I see in forums and Youtube, Live seems the dominant DAW these days, so if Ableton finally implements MIDI 2.0 it would be a huge leap forward.
- KVRAF
- 23077 posts since 7 Jan, 2009 from Croatia
MPE is a part of MIDI 1.0 spec... MIDI 2.0 has a more elaborate framework for MPE sort of stuff. What you linked to doesn't say anywhere that MPE is adopted into MIDI 2.0. Sure it can be translated into MIDI 2.0, but MIDI 2.0 handles things in a much cleaner way (also supporting more than 15 voices of polyphony since polyphonic expression is not shoehorned by using MIDI channels at all).
At any rate, Ableton can't even implement basic MIDI 1.0 stuff like multiple bank/program changes in a single MIDI clip, supporting all 16 MIDI channels in a single MIDI clip, and let's not mention poly aftertouch and so on... I don't think they're in any rush supporting MIDI 2.0. Bitwig will likely get there sooner simply because they're more on top of the game than them.
At any rate, Ableton can't even implement basic MIDI 1.0 stuff like multiple bank/program changes in a single MIDI clip, supporting all 16 MIDI channels in a single MIDI clip, and let's not mention poly aftertouch and so on... I don't think they're in any rush supporting MIDI 2.0. Bitwig will likely get there sooner simply because they're more on top of the game than them.
-
- KVRian
- Topic Starter
- 605 posts since 28 Oct, 2010 from Mexico
Thanks for the clarification about the MIDI spec!EvilDragon wrote: ↑Sat Aug 01, 2020 10:03 pm MPE is a part of MIDI 1.0 spec... MIDI 2.0 has a more elaborate framework for MPE sort of stuff. What you linked to doesn't say anywhere that MPE is adopted into MIDI 2.0. Sure it can be translated into MIDI 2.0, but MIDI 2.0 handles things in a much cleaner way (also supporting more than 15 voices of polyphony since polyphonic expression is not shoehorned by using MIDI channels at all).
At any rate, Ableton can't even implement basic MIDI 1.0 stuff like multiple bank/program changes in a single MIDI clip, supporting all 16 MIDI channels in a single MIDI clip, and let's not mention poly aftertouch and so on... I don't think they're in any rush supporting MIDI 2.0. Bitwig will likely get there sooner simply because they're more on top of the game than them.
I don't want to go off topic since this is a thread about U-He, but every day I find more reasons to switch to Bitwig.
-
- KVRian
- 505 posts since 25 Mar, 2008
No, it was supposed to be a monophonic synth. Thank you for taking a moment for the tip though.Funkybot's Evil Twin wrote: ↑Sat Aug 01, 2020 5:03 amThe Udo Super 6? It's a poly though...
http://udo-audio.com/
- KVRAF
- 23077 posts since 7 Jan, 2009 from Croatia
If you care about MPE you definitely should move since BWS is made with MPE in mind, and it does have better MIDI editing than Live.pierb wrote: ↑Sat Aug 01, 2020 10:23 pmThanks for the clarification about the MIDI spec!EvilDragon wrote: ↑Sat Aug 01, 2020 10:03 pm MPE is a part of MIDI 1.0 spec... MIDI 2.0 has a more elaborate framework for MPE sort of stuff. What you linked to doesn't say anywhere that MPE is adopted into MIDI 2.0. Sure it can be translated into MIDI 2.0, but MIDI 2.0 handles things in a much cleaner way (also supporting more than 15 voices of polyphony since polyphonic expression is not shoehorned by using MIDI channels at all).
At any rate, Ableton can't even implement basic MIDI 1.0 stuff like multiple bank/program changes in a single MIDI clip, supporting all 16 MIDI channels in a single MIDI clip, and let's not mention poly aftertouch and so on... I don't think they're in any rush supporting MIDI 2.0. Bitwig will likely get there sooner simply because they're more on top of the game than them.
I don't want to go off topic since this is a thread about U-He, but every day I find more reasons to switch to Bitwig.
- KVRAF
- 25311 posts since 3 Feb, 2005 from in the wilds
Yup... that's why I switched to Bitwig. My Linnstrument is my most used instrument. Bitwig is all around the best DAW for MPE!EvilDragon wrote: ↑Sun Aug 02, 2020 7:20 amIf you care about MPE you definitely should move since BWS is made with MPE in mind, and it does have better MIDI editing than Live.pierb wrote: ↑Sat Aug 01, 2020 10:23 pmThanks for the clarification about the MIDI spec!EvilDragon wrote: ↑Sat Aug 01, 2020 10:03 pm MPE is a part of MIDI 1.0 spec... MIDI 2.0 has a more elaborate framework for MPE sort of stuff. What you linked to doesn't say anywhere that MPE is adopted into MIDI 2.0. Sure it can be translated into MIDI 2.0, but MIDI 2.0 handles things in a much cleaner way (also supporting more than 15 voices of polyphony since polyphonic expression is not shoehorned by using MIDI channels at all).
At any rate, Ableton can't even implement basic MIDI 1.0 stuff like multiple bank/program changes in a single MIDI clip, supporting all 16 MIDI channels in a single MIDI clip, and let's not mention poly aftertouch and so on... I don't think they're in any rush supporting MIDI 2.0. Bitwig will likely get there sooner simply because they're more on top of the game than them.
I don't want to go off topic since this is a thread about U-He, but every day I find more reasons to switch to Bitwig.
-
Funkybot's Evil Twin Funkybot's Evil Twin https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=116627
- KVRAF
- 11483 posts since 16 Aug, 2006
I'm still hoping VCV Rack modules are up for consideration in the future. Would be nice to get some ACE (osc's/filters/env), Bazille (osc/filters/env), Shape Seq modules, CVlization, etc. in VCV. I know of at least one big developer who designs quality modules who is going to be doing some VCV development in the very near future (don't ask, wouldn't be for me to say who - but it will be a big step up for the platform). Some U-he VCV modules would be a nice way to augment U-he's modular offerings in a more Eurorack environment without hopefully needing a ton of development or building a drag and drop modular environment as a standalone product. My understanding is VCV Rack development is **relatively** easy, I guess it would just need to make financial sense for U-he and somehow fit into the schedule.