Opened 6 years ago

Last modified 6 years ago

#1089 new Feature Request

Support nominalBlockLength

Reported by: falkTX Owned by: David Robillard
Priority: major Component: Jalv
Keywords: Cc:


I'm updating my plugins to use the new nominalBlockLength property. The documentation for the API (juce and DPF) now perfectly matches what LV2 says.


I was wondering if I should keep the old code that used 'max length' but that was never correct to begin with.

Anyway, jalv needs to support this new property.

I made a patch for the initial code, but it will need a macro to test LV2 version. (unless you want to make lv2-git a requirement for jalv)

We'll need to add a call to the plugin's options->set during JACK buffersize changes.

Attachments (1)

nominal-block-length.patch (4.6 KB) - added by falkTX 6 years ago.

Download all attachments as: .zip

Change History (9)

Changed 6 years ago by falkTX

Attachment: nominal-block-length.patch added

comment:1 Changed 6 years ago by David Robillard

I don't really see much point in supporting this dynamically in Jalv. The max *is* the nominal. Plugins should just assume this is the case if nominal is not given anyway (as it was always the case in theory anyway), but it should be passed to instantiate() anyway.

Jalv can just reinstantiate the plugin if the Jack block size changes. Ardour's arbitrary massive max is wasteful and this property should not be used as an excuse to propagate that bad practice to other applications.

comment:2 Changed 6 years ago by falkTX

well, right now in my plugins I just check for the nominal property. I could certainly add a bit more code to check if max == min and then use that value, but seems a little be wasteful when hosts can just pass that property as well (it doesn't hurt or break anything).

comment:3 Changed 6 years ago by David Robillard

It breaks something if that property is not provided, which was the case with 100% of hosts until a few days ago.

comment:4 Changed 6 years ago by falkTX

but those plugins were wrong to begin with.

let's put it this way - adding the new property will help new plugins avoid the old mistakes.

comment:5 Changed 6 years ago by David Robillard

... what plugins?

There is nothing wrong with just using max. That was, and still is, what the overwhelming majority of plugins are going to do, since all they need to do is allocate buffers, and virtually no plugins actually have any use for nominal in the first place.

comment:6 Changed 6 years ago by falkTX

Well, do as you wish, but in any case I'd like jalv to have this property. Other hosts already have it, like ardour, carla and qtractor.

I've made my plugins use the 'nominal' value if available (which matches their wrapper API), and if not they'll use the 'max' value like they were doing before.

comment:7 Changed 6 years ago by Robin Gareus

Currently jalv passes the jack bufsize as instantiation option as "max". jack's max is 8192. As soon as the jack-buffersize increases, things can go wrong.

If you don't want to support nominal, then please also remove maxBlockLength. At least the host won't lie to the plugin about the max in that case.

Alternatively, jalv could simply exit or re-instantiate the plugin, but whatever it does, it must never call the plugin's run() with n_samples larger that what it told the plugin is max during instantiation. Frankly, adding support for nominalBlockLength is a lot easier than the alternatives.

Last edited 6 years ago by Robin Gareus (previous) (diff)

comment:8 Changed 6 years ago by David Robillard

Yes, that is a bug. Jalv should reinstantiate the plugin.

You were so vehemently opposed to Ardour wasting resources with a large static max, but now you want even simple applications like Jalv to follow suit? There's no point in burdening plugins with that extra complexity in this, and most, cases, particularly when its wasting RAM in the process.

I will add nominal, for use as described in the specification (*not* for abuse as the "real max"), but using a static fixed max is silly in something like Jalv, especially when the Jack API doesn't actually provide such information.

Note: See TracTickets for help on using tickets.