View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0007692 | ardour | bugs | public | 2018-11-28 16:30 | 2018-12-18 12:04 |
| Reporter | tassysk | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | new | Resolution | open | ||
| Platform | PC | OS | win7/64 | OS Version | win7/64 |
| Product Version | 5.12 | ||||
| Summary | 0007692: insert or drag plugin is not the same | ||||
| Description | Hi there Tried MB5, Ardour 5, 32c.. Busdriver (Nomad) if first inserted to mixbus (stereo) freezes Ardour and MB. If inserted to tracks or utility buses it is OK. If dragged from a track, where it was inserted, to any mixbuses it is also OK. Aftre that I can insert in mixbuses without any freeze. Seems inserting first to a mixbus or dragged and then insert any makes a difference as dragging first solves the issue. Can be always reproduced. Thanks Tassy | ||||
| Steps To Reproduce | 1. insert Busdriver to a mixbus = freeze 2. open session again 3. insert to track 4. drag it to a mixbus 5. insert into another mixbus 6. insert, drag as many anywhere you like it works | ||||
| Additional Information | Found it in 32c first, John reproduced, told to report you Guys Thanks Tassy | ||||
| Tags | No tags attached. | ||||
|
|
FWIW a Debug build asserts at this line in 'PluginInsert::connect_and_run()':- assert (inplace_bufs.count () >= natural_input_streams () + _configured_out); (though I'm not sure what that's actually testing). Maybe the plugin is reporting the wrong number of channels? |
|
|
After a bit more experimentation, I've realised that my situation is slightly different from Tassy's. If I open the Plugin Manager dialog, then I select the BusDriver plugin, I can drag & drop it to any channel (or bus) without any problems. But if I use the Plugin Manager dialog normally (i.e. by clicking the 'Add' button, followed by 'Insert Plugins') Ardour will always crash - IF - there are no other instances of the plugin (in this session). It makes no difference whether I'm adding to a channel or bus. The crash occurs if I'm using the Plugin Manager dialog normally AND this is the first instance of the BusDriver plugin. |
|
|
Tassy - try inserting 2 instances of the plugin - i.e. with no BusDriver plugins already loaded... 1) Open the Plugin Manager dialog 2) Select the BusDriver plugin 3) Press 'Add' 4) Press 'Add' again 5) Press 'Insert Plugins' In my case, that seems to prevent the crash (although you get an extra plugin that you'll need to remove later). |
|
|
The only thing I've been able to find is that when a plugin gets inserted, the code calls the function 'ProcessThread::get_noinplace_buffers()'. This ends up at a section which looks like this:- if (count != ChanCount::ZERO) { assert(sb->available() >= count); sb->set_count (count); } else { sb->set_count (sb->available()); } Where 'sb->available())' effectively returns a pair of numbers. Whenever the insertion works correctly (for this particular plugin) the returned numbers are [4,2] - but whenever the crash occurs, those numbers get returned as [4,1]. Unfortunately I don't know what those numbers mean or how they get calculated (for example, does the plugin itself play some part in calculating them?) |
|
|
I came across something interesting this morning... Referring to my previous post, it seems that 'sb->set_count()' is setting up a count of the available PortSets. This gets used by BufferSet::attach_buffers() to attach buffers to the available ports - but there's an interesting note in BufferSet::attach_buffers() :- /** Set up this BufferSet so that its data structures mirror a PortSet's buffers. * This is quite expensive and not RT-safe, so it should not be called in a process context; * get_backend_port_addresses() will fill in a structure set up by this method. * * XXX: this *is* called in a process context; I'm not sure quite what `should not' means above. */ Could this explain why inserting the plugin by one method works okay but inserting it by the other method fails ? |
|
|
re [4,2] Does the plugin have two MIDI inputs? In Ardour5, Mixbus5, process buffers never shrink. If, at some point Ardour allocated 2 midi buffers, they'll always be available from then on as thread/process buffers for all threads (this behavior is due to change). re. assert (inplace_bufs.count () >= natural_input_streams () + _configured_out) That is the max possible permutation for plugins that don't support in-place processing (all VSTs) or when routing signals in a non-linear way. Worst case we need to have sufficient buffers to provide all plugin-inputs with a buffer and at the same time be able to bypass the original signal "around" the plugin to all outputs. hence natural_input_streams + configured_out. |
|
|
x42 wrote: " re [4,2] Does the plugin have two MIDI inputs? " No, it requires 0 x inputs and 1 x output (in fact, I think that might be the reason for the problem...) When a plugin gets loaded we call the function 'Route::configure_processors_unlocked()'. It contains a 'for' loop which seems to calculate the requirement for audio channels and MIDI channels (keep in mind that this crash only happens when BusDriver gets loaded for the first time - AND - there are no other MIDI plugins loaded). If I load the plugin normally (using the Plugin Manager dialog) what happens is that the calculation comes out as [4,1]. Later on in the process, I think this is getting interpreted as 4 x audio channels (2 x in, plus 2 x out) and 1 x MIDI channel (1 x in, but 0 x out). But this plugin doesn't require an input; it only requires an output. I think that's what's causing the problem. In fact to test this I tried loading a plugin which has the opposite requirement (1 x input, but 0 x outputs). In that case, the calculation also came out as [4,1]. Something else which might be a factor here is that my particular PC doesn't have any MIDI hardware. In that situation, Ardour seems to manufacture its own virtual MIDI channels, as and when needed - but AFAICT there's an assumption somewhere that if only 1 x channel is needed, it'll be an input. I suspect that a user with actual MIDI hardware would (probably?) never see this crash. Over on the Mixbus forum I've contacted Tassy to ask if his PC also doesn't have any MIDI hardware. [Edit...] FWIW ensuring that the MIDI channels always have an even number seems to fix the problem. Towards the bottom of 'Route::configure_processors_unlocked()' we currently have these lines:- /* make sure we have sufficient scratch buffers to cope with the new processor configuration */ _session.ensure_buffers (n_process_buffers ()); If I change them to this, the problem goes away... /* make sure we have sufficient scratch buffers to cope with the new processor configuration (also ensure that the midi buffers always have an even number) */ if (processor_max_streams.n_midi() % 2) { processor_max_streams.set_midi (processor_max_streams.n_midi() + 1); } _session.ensure_buffers (n_process_buffers ()); I'm not sure if that'll screw up something else but it definitely fixes this particular crash. |
|
|
That is odd issue. Do other generator plugins have the same issue? When you hit that assert, could you print the streams? assert (inplace_bufs.count () >= natural_input_streams () + _configured_out); "natural_input" should be [0,0], configured out is [2,0]. So inplace_bufs must be [0,0] or [1,0] for the assert to trigger. I don't yet see how that can happen, nor why MIDI would be relevant at all. I tried, with test-signal (no inputs, 1 audio out) on a stereo-bus and Dummy backend without any MIDI i/o and cannot reproduce this. The plugin is replicated. This works fine for LV2 and Lua. Perhaps this is VST specific? I cannot easily test that. ThreadBuffers::ensure_buffers() already forces MIDI buffers to be at least 1 (in Ardour5/Mixbus5). So we can't currently have zero MIDI buffers. However I'm about to remove that restriction since we vastly over-allocate buffers (VST MIDI buffers are 4MB per thread per channel for no good reason and we waste a few hundred MBs in total for nothing in BufferSet::get_vst_midi). |
|
|
I don't seem to have test-signal, except as an unrelated python script somewhere (I'm guessing it should be a plugin?) but this got me confused:- x42 wrote:- "natural_input" should be [0,0], configured out is [2,0]. [...] ThreadBuffers::ensure_buffers() already forces MIDI buffers to be at least 1 " I don't understand how you're seeing 0 for the 2nd value if there always needs to be at least 1 x MIDI buffer?? Anyway... these are the values I see here whenever the assertion triggers:- '_configured_out' is [2,1] the returned value from 'natural_input_streams()' is [2,1] the returned value from 'inplace_bufs.count()' is [4,1] and if I apply my patch (from post #0020520) 'inplace_bufs.count()' will increase to [4,2], which the assertion accepts (i.e. it stops the crash). |
|
|
I have some new info about this Busdriver issue: inserted on stereo track it freeze/crash, dragged from mono it is OK. I have read here you have found some MIDI I/O alomany I made some experiment and it is as follows: On my Mixbus 32C plugin manager opens a bit narrower, so have never seen the MIDI column, Now John called my attention and now I checked all my plugins that have some MIDI I/O -Busdriver O crash -Plug and mix all the 8 plugs I have O crash -Melodyne I -Mikron Reverb I -Protoverb I -Waves Tune rt I -The Glue I O Tried all and it shows that if the plugin has Input then it behaves as normal plugs, no issue. Plugins crash Ardour and MB if they have only Output and no Input. Crash I mean when first inserting into stereo bus. After a plugin having only Out is inserted into a mono track and dragged into stereo, it works. Also interesting that after this the plugin can be removed and the session still accepts the new insert. I am no programmer but think that the firts install on mono track somehow changes the behaviour of the stereo tracks and make them forget to crash:) I hope it gets you guys closer to fix it thanks a lot best wishes Tassy |
|
|
I still cannot reproduce this issue. Create a new empty session, add either a mono OR a stereo audio track. Add "Test Signal Generator" [1] from utilities. All is fine. The only listed plugin that I have access to is Uhe's protoverb. That doesn't crash either. Prooverb does however have 2 audio inputs, 2 audio outputs and MIDI input.. and in fact it's a known to be good VST for many other users. This is getting more and more mysterious :( [1] https://x42-plugins.com/x42/x42-testsignal (0 in, 1 out) |
|
|
No mistery, Prooverb has MIDI input so works fine. In my list "I" and "O" after the plugin name mean MIDI Input and Output (Prooverb I) has MIDI Input, no crash (Waves Tune rt I) has MIDI Input, no srash (melodyne I) has MIDI Input , no crash (Glue I O ) has MIDI Input and Output, no crash (Busdriver O) has only MIDI Output, crash (PLugandMix O) all have only MIDI Output, they crash Only the plugis that have ONLY MIDI OUTPUT and NO Input do the crash. Plug and Mix all I have crash, they have only MIDI Output, no Input Busdriver the first I found also has ONLY MIDI Output no Input so it crashes Tassy |
|
|
Robin - I followed your link (above) but it seems to be a LV2 plugin. As far as we know, the problem is specific to VST plugins. [Edit...] and in any case, your tone generator plugin doesn't support midi AFAICT. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2018-11-28 16:30 | tassysk | New Issue | |
| 2018-11-28 16:59 | johne53 | Note Added: 0020489 | |
| 2018-11-28 17:00 | johne53 | Note Edited: 0020489 | |
| 2018-11-29 17:06 | johne53 | Note Added: 0020493 | |
| 2018-12-01 14:38 | johne53 | Note Added: 0020500 | |
| 2018-12-04 15:04 | johne53 | Note Added: 0020508 | |
| 2018-12-05 08:54 | johne53 | Note Added: 0020509 | |
| 2018-12-06 19:17 | x42 | Note Added: 0020517 | |
| 2018-12-07 09:47 | johne53 | Note Added: 0020520 | |
| 2018-12-07 11:53 | johne53 | Note Edited: 0020520 | |
| 2018-12-07 11:56 | johne53 | Note Edited: 0020520 | |
| 2018-12-07 12:00 | johne53 | Note Edited: 0020520 | |
| 2018-12-07 12:01 | johne53 | Note Edited: 0020520 | |
| 2018-12-08 16:41 | x42 | Note Added: 0020523 | |
| 2018-12-09 08:42 | johne53 | Note Added: 0020524 | |
| 2018-12-09 08:43 | johne53 | Note Edited: 0020524 | |
| 2018-12-15 20:40 | tassysk@gmx.com | Note Added: 0020532 | |
| 2018-12-15 21:14 | x42 | Note Added: 0020533 | |
| 2018-12-16 08:39 | tassysk@gmx.com | Note Added: 0020535 | |
| 2018-12-18 11:43 | johne53 | Note Added: 0020541 | |
| 2018-12-18 11:46 | johne53 | Note Edited: 0020541 | |
| 2018-12-18 12:04 | johne53 | Note Edited: 0020541 |
