I ported Bidoo modules

danngreen · March 7, 2025, 1:09am

There’s the AsyncThread API, which is already in v2.0-dev. It can be used to exactly what you’re saying – run a task such as loading a big file in the background without interrupting the audio. When the task is done, it can set a flag that the audio loop sees and then does whatever it needs to do (starts playing the new file for example)

danngreen · March 7, 2025, 1:16am

Sounds like filesystem stuff is happening in the audio loop. Glancing at the source code, yep that’s whats happening: it’s loading and saving samples to disk in the audio process() routine.
So those calls will need to be put into AsyncThreads. @etcetc I can help show you how to do that, it’s fairly simple:

github.com

4ms/metamodule-plugin-sdk/blob/v2.0-dev/docs/async-threads.md

## Async Threads

If a certain task can't be performed in the audio task because it does not meet
real-time requirements (for example, allocating memory or reading files, or
performing complex analysis such as large FFTs) then it can be run in an
AsyncThread.

The API is defined in [`CoreModules/async_thread.hh`](https://github.com/4ms/metamodule-core-interface/blob/v2.0-dev/CoreModules/async_thread.hh)


### Usage

Create an `AsyncThread` object in your module class. Provide `this` (which is the pointer
to your module) and a callable object (e.g. a lambda) in the constructor. When
you want the thread to start running call `start()`.

```c++

    AsyncThread async{this, []() {
        // do something in the background

This file has been truncated. show original

etcetc · March 7, 2025, 6:22am

interesting, I’ll try to replicate this and will do the async thread work. I have to clean up a bunch of other port repos as well

modular_fiddler · March 7, 2025, 7:43am

I have one running 2400 64B and get big spikes with CPU warnings. it runs at 33% other wise. Increasing block size… to 128 helps. 512 is better

still crashes occasionally-

offthesky · March 15, 2025, 1:51am

@etcetc im also finding some not so favorable behavior in canard where, with longer samples (30 seconds+) it only loads part of the sample, it seems to cut off around the halfway point. ish. does the module impose a weird limit on how much it will load or display? seems to occur in vcv as well.

not sure how i didn’t notice this before. sadly kind of renders the module a bit unusable

etcetc · March 15, 2025, 3:16am

Haha well I feel a little bit better if it happens in VCV Rack…

We might need to take a step back from this as I am cleaning up repos. I’m sure you would prefer to have working VCV Rack implementations as well, so I might need to see if I can send some code pull requests to fix this.

I can’t give an estimate unfortunately, have been really busy at work as of late. If there is another suitable sampler for you in Bidoo let me know or any other library. There’s still a few in Bidoo I haven’t ported in terms of samplers but they might very well have issues themselves

offthesky · March 15, 2025, 4:28am

all good! as you know we all really appreciate the efforts/additions you’ve given us here. i tried the other samplers in the bidoo line you ported - ouaive and edasaros. both exhibit the same problem. i see 3 others in vcv that i don’t see in mm: poupre, magma, and oai… so i won’t bother testing those in vcv.

as far as other library, voxglitch have a bunch of awesome samplers(specifically the looper or repeater modules). CF is an old school (pre1.0vcv) line that has a sampler player ive used a bunch in the past. it’s interesting the panel says ‘bidoo’ on it but after testing it in vcv, it doesn’t have the truncation problem as all the bidoo ones have.

offthesky · March 17, 2025, 7:43pm

reported the bug here so hopefully will see a fix at the source at some point:

etcetc · April 10, 2025, 10:36pm

I’ve fixed the above half-loading issue and added a few more samplers. I also moved all sample loading and saving to async thread to not cause audio issues when switching samples.

I also fixed a bunch of crashes related to playing while loading samples.

Fixed a bunch of issues with gate inputs requiring nearly a perfect 0V to turn off.

I have not tested everything - Canard seems to be more stable for me.

Also annoyed me that certain jacks/inputs weren’t labeled, so I labeled them so they show up in the MM

danngreen · April 10, 2025, 11:00pm

We just went through all these (Bidoo-v1.0), here are some notes about issues (you may have fixed some of these already since you just made an update)

Edsaros: uses arrow glyphs that aren’t in the default MM font (I’m not sure what font it’s expecting to have?). Suggest replacing with ASCII chars or specifying a font that has those glyphs.
Lourde: draws text sideways. MM firmware would need to interpret the transformation and apply a style rotation, I’ll put in an issue for it.
Dtroy: crashes when adding to a patch. I got it to run for a brief moment once, but usually crashes immediately. Debugger shows it crashing in malloc, I didn’t dig further.
-~Lots of modules have generic knob/jack names like “Param 1” and “In 11” (e.g. Canard, BAFIS, most others). Since the artwork is often barely legible, it would be nice to use the configParam and configInput/Output feature of Rack to set those names.~ Edit: saw your post above, Nice!!

etcetc · April 10, 2025, 11:38pm

Yea… dtroy is weird. Will remove it for now.

Also replacing arrow glyphs, thanks!

danngreen · April 11, 2025, 6:11am

Cool, thanks. I figured out it’s wanting to use DejaVuSans, which has those glyphs. But even with that font, they’re not legible, so its still a good idea to replace them and/or fiddle with font size/color/position.