Boscop

yeah we could use ArrayVec

There are also allocations in [`interfaces::read_string()`](https://github.com/overdrivenpotato/rust-vst2/blob/master/src/interfaces.rs#L315-L319) and the [`collect()`s in AudioBuffer](https://github.com/overdrivenpotato/rust-vst2/blob/master/src/buffer.rs#L33-L52). The string length is bounded so we can just preallocate that mem, but more important is removing the allocs...

Plugins allocate memory for their specific needs in their `init()` method.

It depends on how to buffers are used. Putting them all together when they are used in different contexts doesn't improve cache locality.. So it's really specific to each plugin..

I'm running into this too! Please fix this :)

@VolodymyrOrlov Thanks for your great work, I'm looking forward to this being merged :)

More tests, this time they occur after loading a couple other VSTs before: http://www.vst4free.com/free_vst.php?id=1342 "D:\VstPlugins\Distorque\Azurite.dll" msvc debug output: Exception thrown at 0x6F5D346B (Azurite.dll) in vstscan.exe: 0xC0000005: Access violation reading location...

Can anyone reproduce this behavior? I'd also be interested in whether the scanner works on your system even if it's not windows :)

In my `vec_map` macro (for [`VecMap`](https://contain-rs.github.io/vec-map/vec_map/struct.VecMap.html)) that was modelled after the maplit macros, I got bitten by this. I ended up adding an assertion: ```rust macro_rules! vec_map { (@single $($x:tt)*)...

@Nokel81 Thanks! Could you also support this syntax? `vecdeque![expr; N]` Like `slice-deque`'s [`sdeq`](https://docs.rs/slice-deque/0.3.0/slice_deque/macro.sdeq.html) macro: ```rust let v = sdeq![Rc::new(1_i32); 5]; ```