controller for DIVA

[xh3rv]

Ahh, ok. Btw It's related to church pipe organs, and the length of the pipes in feet Vs pitch they produce

That makes a lot more sense than what I was guessing

[PAK]

Resposted with "no names"

So, no change of heart on this then? Expecting users to use MIDI to work around this on Novation controllers is not a solution because it negates the whole point of using an Automation based "auto-mapping" controller in the first place! It'd just be nice to know there's possibly a better reason than "because we say so, and that's how it is" before Urs appears to proceed to do a bit of a *censored* on this.

Doing A *censored*: The questionable act of leaving a small number of key controls out of DAW automation whilst mysteriously leaving them automatable via MIDI CC. Cynically minded persons may allege this was done to impede the plugins ability to work with automation based hardware controllers, thereby placing the plugin vendors own (more limited) conventional MIDI CC based hardware controllers at a less competitive disadvantage. Obviously such thinking is wrong. *censored* did it like this because they love their customers, not because of concerns about competing hardware controllers such as Novations.

Admittedly Diva's issue isn't as bad as pulling the plug entirely! It leaves a window open for Novation to code a work-around. Whether Novation will or not would be questionable since it doesn't seem to apply to any(?) mainstream plugins beyond Diva, and could be seen, by them, as setting a precedent to have to code work-arounds for vendors who decide to depart from conventional practises and implement other non-standard controls for no apparent reasons nor benefits.

So forgive my persistence on this. I just question why Urs would push ahead with this despite knowing that it breaks how one of the most popular controllers works, and just about the only viable automation based one presently on the market at that!

It'd be a lot more understandable if good reasons could be given for doing this (none of which I can think of). I also can't think of anyone else in the VST world who does it like this. Best of all, it brings absolutely no advantage for actual hardware control because it still takes 2 physical controls to automate properly anyway! The only thing it does succeed in is partially breaking Diva's octave switch with Novations automation system. So what other reasons are left to do it this way? Stubbornness?

It just sucks to see Novation users get similar lovin' from Urs on this one that I'd expect more from companies like *censored*.. Oh well.

[xh3rv]

If someone's on Novation and really needs footage they can use a generic MIDI device control. I really wouldn't be surprised if using generic MIDI is better for other reasons anyway - paging sucks in Automap, having a second GUI open to see mappings is a pain, etc. It can't be any worse than using any other MIDI controller.

[e] As far as host automation, it's not really the case that isn't automatable either - the 60-semitone range is available on the Tune# parameters the footage and detune knobs map to. I sort of don't really see where more would be absolutely necessary given that most synths don't work any differently, it's not something I've ever seen anyone take issue with before :S

[PAK]

If someone's on Novation and really needs footage they can use a generic MIDI device control.

As stated, I don't feel that represents a good solution to me, nor the best solution to other Novation users either. It also ignores that Diva is implementing a control in a manner which seems to make little sense, and that this is what is causing the issue in the first place. Rather than suggest a work-around I've already stated is unsatisfactory (Because it defeats the purpose of using automation based controllers), why not question the reason/motivation for implementing the control in a manner uncommon for VST's which also gives no apparent benefits?

I sort of don't really see where more would be absolutely necessary given that most synths don't work any differently

Except they do. It's not common to see octave and detune switches sharing the same automation value on VST's, with different operating ranges expected on each. If you think it is then, err, ok.

[Howard]

...why not question the reason/motivation for implementing the control in a manner uncommon for VST's which also gives no apparent benefits?

The idea was simply that it would be nice to have the "fine" control endless, the footage is just a different "view" of that same control. No reason to suspect an evil plan. Aren't the benefits obvious?

[PAK]

...why not question the reason/motivation for implementing the control in a manner uncommon for VST's which also gives no apparent benefits?

The idea was simply that it would be nice to have the "fine" control endless, the footage is just a different "view" of that same control. No reason to suspect an evil plan.

It could still be done endlessly with Octave implemented as a separate controller message. You're just talking about the ability of the detune to travel the entire pitch range. Diva could handle the +/-12 octave switching internally on receipt of a controller message to know to change the octave up or down. It then sends this position status update to the controller so that, if it's using a rotary encoder (which you'd want to do anyway - the 6001 step resolution of detune as implemented in Diva is too high for standard MIDI controls), it won't even mean the pitch would suddenly jump when you use detune again. There's a reason it's generally implemented this sort of way

Aren't the benefits obvious?

No. For such a large range to be usable you'd have to rotate the control a lot. It's that or reduce the sensitivity of the control so it can travel the entire range in a reasonable amount of turns.

The third alternative would mandate that acceleration be used for that particular control (so it knows to speed up with quick movement and use finer resolution for slower movements). However it (seems to be) common that controllers implement this option on a global basis rather than on an individual knob basis. So users would have to opt for acceleration on everything or nothing to choose this.

Besides which (I think) generally people want 2 controls for this stuff anyway - a "take me there quicker" Octave knob, and a finer resolution detune control.

[hakey]

Those who use Automap with Zebra, Diva or Ace - (Diva coarse/fine tune aside ) is it worthwhile?

[PAK]

Those who use Automap with Zebra, Diva or Ace - (Diva coarse/fine tune aside ) is it worthwhile?

I can upload some maps for Diva if you want? They've sat at about the 80% finished mark since my motivation to finish them was low when I learned that something better was maybe in the pipeline for Diva - And it is - the coming updates sound cool and will be extremely helpful in cutting down page scroll (the need to switch pages on Automap) provided the new changes have been adequately exposed for host (not just CC) automation.

Such maps requiring "learning" - I'd estimate it'd take at least 20 hours of usage before the level of frustration starts to drop and locations begin to "click". Basics (ADSR etc) are obvious though.

Worth it? It's faster to do some stuff, and you will program slightly different sounding sounds than you would do if you stick to only the mouse (my experience at least - there's more "happy accidents" with hardware control).

I always try to make maps that mirror the GUI, but it's easier said than done when controls with a "middle", and more than very limited resolution, basically need rotaries to function correctly. Plus things like the mod destination pull down menus are really best left off since only a masochist would use a controller over a mouse to select those (Unless it was a touch screen menu ).

[hakey]

I can upload some maps for Diva if you want?

I'll wait and see what the new version offers - thanks for offering to share.

[Howard]

... the 6001 step resolution of detune as implemented in Diva is too high for standard MIDI controls)

OK, understood now . BTW acceleration: I *loath* the feel of accelerated controls/mice!

[Urs]

The parameter is oscillator tune. The GUI representation splits it in an octave switch and a finer grained 1200 cents knob in order to accommodate usage with a mouse. Period.

If a control surface hasn't been built with the vision that a user might want to have coarse and fine control over a single parameter then this is not and will never be *our* problem.

#---

Regarding "hidden parameters": Say your thanks to Apple for having had a bug that prevents AUs from working properly with 500+ parameters. Also convey thanks to Ableton for having had a parameter limit of 128 in Live for years. This made restrictions in the number of visible parameters necessary. Not our fault.

While these shortcomings have been fixed for a while, we can't just unleash every parameter. It would break backwards compatibility of existing projects that have automation tracks.

Ou latest products such as Diva make all parameters available for automation that are also represented in the gui and which are not globals/preferences.

#---

I furtherly do not accept competitor bashing in my forum. Thus I'm going to edit a post here.

[PAK]

If a control surface hasn't been built with the vision that a user might want to have coarse and fine control over a single parameter then this is not and will never be *our* problem.

You can blame the problem on Novation Urs. But guess what? The end user doesn't care whose problem it is, they just know Diva doesn't work as expected. Who is going to fix it for them?

The answer is "not U-He". U-he software doesn't care if it implements things in ways that break how another companies controller works. It's the other guys fault. Stellar customer service there Urs. Thanks.

Now all anyone needs to do is go to cap-in-hand to Novation and hope that MAYBE they'll fix a problem caused by what can only be termed an "unconventional" implementation of a MIDI control. Let's ignore that, in your response, you still haven't given a valid reason for implementing it this way IMHO, other than "we done it this way, tough luck if you don't like it". You've certainly won me over. I now understand why you did it this way when pretty much nobody else does. Cheers.

Apple
<snip> restrictions

Nah.. Really? Any other shocking revelations?

Not our fault.

I'd gathered this was the running theme.

Maybe you'd be so kind as to report the problem to Novation directly yourself then? Or is that also too much to ask and "not your problem?"

But I'm glad you're happy with how you've implemented it. Shame it kinda says "screw you" to Novation users IMHO. I'm sure any forthcoming controllers endorsed by U-He won't have the issue though, so that's good to know.

I furtherly do not accept competitor bashing in my forum. Thus I'm going to edit a post here.

You deleted my entire post, which contained approximately four words you apparently objected to. That's a bit heavy-handed, no? I've thus taken the liberty to redact any names and repost it without naming any competitors. Since this was your problem with the post you shouldn't have any issues with leaving the post intact "as-is" now? Please inform me of specific content you object to - rather than entirely removing what I regard to be valid criticisms. Or is that also too much to ask?..

[Mogular]

Wow, do you seriously think that Urs is an asshole?

[PAK]

Wow, do you seriously think that Urs is an asshole?

No. I'm just struggling to understand his reasoning. It may be perfectly well meaning. All I know is I have an issue with his software, I understand the issue fairly well, and IMHO it's as much "U-he's" fault as Novations.

I can, and do, blame both companies. What I object to is "buck passing" when a customer has a problem and, in my opinion, there is more compatible way to do the same thing, and it's within U-he's power to fix it. I figured we (Novation users) maybe have a better prospect with him than Novation. Guess what? I was wrong.

[Urs]

Gosh. What's your problem?

Our implementation is simple:

There's a parameter that allows for control of oscillators from -30 semitones to +30 semitones. This parameter can be seamlessly automated in the full range with a single automation track. We also consider this a modulation target for a ModMatrix, should we be able to implement one with the multicore functionality.

We added customised knob controls on the user interface to make typical ways of mousing easier, without breaking the chance to do full range automation with no steps.

If we split this parameter up into two indepoendent parameters (octave/semi) then there's no way to do such sweeps in automation tracks. There's also no way to use a modmatrix to sweep the full range.

That's the reasoning behind it, end of story.