Issue - duplicating modules with binary resources

[Waverley Instruments]

Howdy VM Developers,

I've noticed something a bit odd with a module that uses binary resources when duplicating it. It appears to me that duplicated modules are possibly sharing the resources of the original, and if you remove the original, the duplicate(s) can no longer access those resources. And the odd thing is, if you add the same module back (via the library browser) all is OK again.

GetBinaryResource() is basically returning null after the original module is removed.

Weird, huh? Can anyone else confirm / deny if they've seen this with their modules? Could be something specific to the module itself I guess.

In this specific case, it's loading presets from ANALOGy5 which are stored as binary resources (ANALOGy5 has its own preset management system).

Update: re-launching VM seems to clear the error condition and all modules are accessing resources OK.

I've opened a support request with CA and will update here with any info.

Thanks, -Rob @ Waverley Instruments

[Waverley Instruments]

Little update on this. I'm able to reproduce the issue with a simple test module that basically just does this when a button is clicked:

Code: Select all

            ByteBuffer buffer = GetBinaryResource("test.bin");
            if (buffer == null)
               statusLabel.SetText("BUFFER IS NULL!");
            else
               statusLabel.SetText("Buffer: " + Integer.toString(buffer.remaining()) + " bytes");

[ColinP]

That's odd and rather worrying.

I'd always assumed that duplicate simply created another instance of the module and then transferred the state using the same event and stateInfo mechanisms as are used to save and restore patches.

It shouldn't be sharing any object references. Although if it did one would expect them to be immutable and managed by the garbage collector.

Sounds like a bug in the C++.

[Waverley Instruments]

Sounds like a bug in the C++.

It's looking that way! At first I thought maybe there was a close() method on the ByteBuffer I'd missed or something like that, but of course, they get GC'd.

Anyway, it was a "fun" one to track down, so hopefully this might be handy for anyone else scratching their heads between now and when it gets fixed / there's a workaround. Regarding the latter, nothing springs to mind, sadly.

[ColinP]

Presumably only ever calling GetBinaryResource() in Initialize() would be a workaround?

[Waverley Instruments]

Hmmm... I guess in some cases, maybe?

Not in the case when your binary resources are 100+ "factory presets" Don't think I'd want to pre-load those.

[Centripidity]

Hmmm... I guess in some cases, maybe?

Not in the case when your binary resources are 100+ "factory presets" Don't think I'd want to pre-load those.

Would that be a problem? I don't know, I'm just asking. Memory is cheap and processors are so fast now. What would the issue be?

[Waverley Instruments]

What would the issue be?

Personal opinion, but pre-loading 100+ presets, that might some day be 1000, for a user that might never need them just feels plain wrong to me

But my background is mobile / embedded when memory wasn't cheap and processors weren't fast

In my specific case, my preset files are around 1.5K which is approx 1K less than an equivalent .modpreset file, interestingly enough. So we're not talking humungous amounts of data here, to be fair.

Also, pre-loading, at least to my mind, would be a workaround for a VM issue that's arguably an edge case. Hard to say how many users duplicate modules then delete the original in their normal workflow, but I suspect it's not that many when the module happens to be a self-contained instrument.

My ideal scenario is the guys at CA fix it My €0.02 - Rob

[ColinP]

It's a bug and should be fixed but I don't see any problem in loading a few MB of data on intialization these days. Although I used to write entire games that ran in 48 kB so understand the instinct not to.

AFAIK the bulk of the delays we get on initialization in software aren't due to loading but rather object instantiation. This certainly used to be the case when I was doing OOPL research on a Sun SPARC machine back in the 1990's and I think drives have become faster and object models more complex since then so it's likely even more the case now. Just loading a large chunk of raw data is not particularly taxing.

[ColinP]

Another thought is that the resources might actually all be loaded on initialization anyway with GetBinaryResource() doing nothing more than mapping keys to pointers.