DS404: Problem with embedded sample data
-
- KVRist
- 196 posts since 12 Mar, 2002 from Mountain View, CA
Thanks for releasing DS404 to CM users. It's amazing that you can get a sampler for the price of a magazine!
I ran into a snag when using DS404 with Plogue Bidule. The symptom is that if I save a .bidule file that uses DS404, the file is enormous and takes a long time to load. I'm guessing that when Bidule requests parameters from DS404, it receives the sample data along with all the other params.
Is this an issue that's on the Bidule side or on the DS404 side? Would it be possible to split out the sample data? The host could receive a filename from which to load the data, instead of receiving the data itself.
Boris
I ran into a snag when using DS404 with Plogue Bidule. The symptom is that if I save a .bidule file that uses DS404, the file is enormous and takes a long time to load. I'm guessing that when Bidule requests parameters from DS404, it receives the sample data along with all the other params.
Is this an issue that's on the Bidule side or on the DS404 side? Would it be possible to split out the sample data? The host could receive a filename from which to load the data, instead of receiving the data itself.
Boris
-
Muon Software Ltd Muon Software Ltd https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=89
- KVRian
- 1461 posts since 21 Nov, 2000
You are correct having guessed that DS404 is sending the sample data. That is the way that it works in all hosts.
However, it shouldn't take all that much extra load/save time - it makes hardly any difference in other hosts that we've tried. I could raise this with the Bidule developers for you if you like.
Regards
Dave
However, it shouldn't take all that much extra load/save time - it makes hardly any difference in other hosts that we've tried. I could raise this with the Bidule developers for you if you like.
Regards
Dave
-
- KVRist
- Topic Starter
- 196 posts since 12 Mar, 2002 from Mountain View, CA
Yeah, that would be great if you could look into this issue, to see if anything could be done. After loading some of the larger instruments, I noticed that the size of my .bidule file grew from 2k to 20MB and took about 30 seconds to load and save. Maybe there could be some sort of option in DS404. If the box is checked, it sends the path to the .404 file to the host instead of the sample data. Then when DS404 is initialized, it loads the sample data from the original file.
I'll experiment with this some more over the weekend, to see if there's a performance difference between loading the data from the original .404 vs. from a .bidule file.
Thanks for looking into it,
Boris
I'll experiment with this some more over the weekend, to see if there's a performance difference between loading the data from the original .404 vs. from a .bidule file.
Thanks for looking into it,
Boris
-
Muon Software Ltd Muon Software Ltd https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=89
- KVRian
- 1461 posts since 21 Nov, 2000
DS404 can't be changed in this way - see my other mail elsewhere on this forum regarding feature requests on the CM instruments 
I should point out though that if you load a 20mb instrument into DS404, your saved song will be at least 20mb in size. To expect otherwise would be, well, silly.
I'll have a word with the Plogues about the slow load/save times though. It certainly doesn't take DS404 30 seconds to load a 20mb file on a reasonable machine
Dave
I should point out though that if you load a 20mb instrument into DS404, your saved song will be at least 20mb in size. To expect otherwise would be, well, silly.
I'll have a word with the Plogues about the slow load/save times though. It certainly doesn't take DS404 30 seconds to load a 20mb file on a reasonable machine
Dave
-
- KVRian
- 928 posts since 3 Aug, 2001 from Montreal
Hello
We are aware of the problem, The reason it takes a while is that we convert the binary data to base64 in order to put in in our xml files(ascii).
When I coded this i only came accross plugin chunks that
were half a megabyte in size in the worst scenario,
and the load/save proved efficient enough.
Now i never planned plugs would save 13.6 megs of data
( 20*6/8 ) since we convert it to base 64...
I guess ill have to find ways to make our conversions more efficient.
Sorry for the temporary inconveniences,
David
We are aware of the problem, The reason it takes a while is that we convert the binary data to base64 in order to put in in our xml files(ascii).
When I coded this i only came accross plugin chunks that
were half a megabyte in size in the worst scenario,
and the load/save proved efficient enough.
Now i never planned plugs would save 13.6 megs of data
( 20*6/8 ) since we convert it to base 64...
I guess ill have to find ways to make our conversions more efficient.
Sorry for the temporary inconveniences,
David
David Viens, Plogue Art et Technologie Inc. Montreal.
https://bsky.app/profile/plgdavid.bsky.social
https://plogue.com
https://bsky.app/profile/plgdavid.bsky.social
https://plogue.com
