I ported Noi modules

etcetc · February 27, 2025, 12:15am

Beautiful VCV lineup, surprised I haven’t heard of them before.

v2.0.0-dev12.2 needed.

https://drive.google.com/drive/folders/1UWzGrsmvtfXJEDopqq1BTxEoySWiCwic?dmr=1&ec=wgc-drive-globalnav-goto

offthesky · February 27, 2025, 2:34am

these are really awesome, loving the resonator and grain verb, ty much!!

marsona · February 27, 2025, 4:54am

Hey Thank you! That was fast!

Just out of curiosity, once the 2.0 firmware becomes official does that mean that these along with the other ported modules on this forum would be part of or available on the main downloads page or will ported plugins always be found in their respective githubs?

etcetc · February 27, 2025, 5:30am

Great question. I have been very lazy about my mm-plugin metadata setup, not sure if @danngreen can answer how I can best keep that tidy for future release (or potentially get them listed on the 4ms plugins site?)

danngreen · February 27, 2025, 7:21pm

We’ve been thinking about this, too. I’m typing up a README for publishing releases right now.

The way our website works is we give it a list of github repos and a list of plugin names to search for in those repos. The .mmplugin file needs to be in a Github Release. Our script scans the Releases for the latest version. Versions like vX.X-dev-12 will go into the dev plugins zip file, and versions without the current dev version string will get listed on the main plugin site (unless they are version v0.x or contain dev in the version name).

Also, the plugin-mm.json file will need to contain the list of modules.

danngreen · February 27, 2025, 10:16pm

I wrote up a bit about what’s needed for a plugin to be scanned by our scripts and hosted. There’s a fair bit of complexity since there could be multiple versions, and certain versions work with v1.x firmware vs v2.x latest firmware vs. older v2.x firmware… But I think we have it figured out now.

github.com

4ms/metamodule-plugin-sdk/blob/main/docs/release.md

# Releasing a MetaModule Plugin

Now that you have a working plugin, it's time to share it with the world!


### Licensing

According to the license, you are free to release your plugin under any license
you wish, including commercial licensing. Your choice of license needs to
comply with the license of any code that you used.

## Listing on the official MetaModule plugins page

The official MetaModule plugin page is at [https://metamodule.info/plugins](https://metamodule.info/plugins)

We want this page to list all plugins that are available for the MetaModule
platform, so we encourage you to list your plugin here if you want others to
use it.

Whether your code is open source or closed source does not effect how the

This file has been truncated. show original

I tried to put all the info in this document, including an example github workflow script (which is not necessary but is nice because it builds it for you). You also can manually create releases on github and upload the file you built.

Let me know if you need help getting any of that set up.

Jdubbs87 · March 3, 2025, 10:04pm

Thank you so much for porting

etcetc · March 26, 2025, 6:31pm

Updated with a cleaner repo and I think a new NOI looper module called pruners (?)

I also updated the plugin-mm.json - to save your sanity @danngreen should I tag you each time I provide a valid plugin-mm.json to request it being listed?

danngreen · March 26, 2025, 7:42pm

Great! All that needs to happen is the .mmplugin file needs to appear in the Releases (here: Releases · Ericxgao/metamodule-nozori · GitHub)

You can manually create a release (“Draft New Release” button) or you can use a github workflow to do it automatically. I have a sample workflow file and some screenshots to help with that process in the release README: metamodule-plugin-sdk/docs/release.md at v2.0-dev · 4ms/metamodule-plugin-sdk · GitHub

The other thing is to follow the naming convention outlined in that document when you name the .mmplugin file. This helps our website knows which version is which (e.g. dev-12 or some other dev, or if it’s a v1.x plugin). Also good naming helps users know if they have the latest version or need to download a new one, and which firmware a given mmplugin file will run on.
The mmplugin file needs to be named like this:
[BrandSlug]-v[plugin-version]-[sdk-version].mmplugin

So it could be Nozoid-v0.2-dev-12.mmplugin for instance if it’s built with the dev-12 SDK and you want to call your build “v0.2”. Then the next release you make, you will bump your version up, perhaps to Nozoid-v0.3-dev-12.mmplugin. When we release dev-13 (soon), you’ll need to re-compile with the new SDK and call the file Nozoid-v0.3-dev-13.mmplugin

Once we have v2.0 as official, then the tag will change from dev-13 to fw-2.0.

Yes, that’d be great, just PM or tag. I’ll run the scan+update script which will check your repo for new releases and put them on our site.
We also will periodically scan for new releases, so if you publish anything new that matches that naming format, then it’ll eventually end up on the site even if you forget to tell us.
If by change you want to publish a release but don’t want it on our site, you can mark it as a “Pre-release” or just don’t use the exact naming convention.

marsona · March 27, 2025, 5:16pm

@etcetc thanks for your hard work, been using these consistently since you ported them.

danngreen · April 12, 2025, 12:22am

It looks like Hellebore has a memory leak of around 8-9MB or so.
To see:

Check the free RAM (e.g. 139MB)
Create a new patch with Hellebore only
Check the free RAM (e.g. 157MB)
Close that patch by creating another new patch with no modules (or pick the 4ms Atvert2 or some thing known to not leak)
Check the free RAM (e.g. 148MB)

Each time you add a Hellebore and then close the patch, memory grows by about 3% (or about 9MB) and never comes down.

The cpu-load tester found this problem, it ran out of memory trying to run patches with this module at various block sizes and jack/knob configurations.

etcetc · April 12, 2025, 9:28am

Fixed in the latest release and managed to optimize it to bring down to 50% cpu

danngreen · April 13, 2025, 7:58pm

Looks good now.
Sinesis is crashing the cpu load tester now. I was able to get it to crash by creating a patch of several Sinesis, auto-mapping one of them and then closing and re-opening the patch.

etcetc · April 13, 2025, 9:26pm

Thanks - I think fixed now, I had to just rebuild it on the latest plugin-sdk.

danngreen · April 16, 2025, 9:48pm

I’m still getting Sinesis to crash, using the v1.0.3-dev-13 release.

Unfortunately I haven’t been able to reproduce it when making a patch manually. The CPU load tester crashes 100% of the time on this module, but making a patch manually only crashes occasionally.

I’m deep into debugging the plugin unloading/reloading crash, but this one is the only module failing in the cpu tests so I wanted to report it.

Any ideas? I’ll try debugging it when I get a chance.

etcetc · April 17, 2025, 1:53am

Hmm that’s odd. I’m trying to reproduce it on simulator but no luck - not sure how else to fix it if I can’t get stack trace, if you have any ideas.

danngreen · April 17, 2025, 2:26am

Yeah I thought I had a totally reproducible test case and then it just started working again.

I’ll put the JTAG debugger on it while the CPU load test runs and hopefully get something useful from that.

danngreen · April 17, 2025, 6:17pm

Aha! Sinensis is OK, it’s Pruners that has a memory leak.
It’s not huge enough of a leak to crash while testing Pruners, but it leaves little free memory for Sinensis to run, so that’s why it crashes on that module.

danngreen · April 17, 2025, 6:55pm

Ok… so it’s true Pruners has a memory leak. I think it might be from this extra allocation:

github.com

Ericxgao/NOI-VCVRACK/blob/65f0a099783c5afeb6b7c16d4ba88a8428f4aec1/src/RingBuffer.cpp#L12


      
          
          
          
          namespace noi {
          
          /// @brief constructor for ring buffer
          /// @param max_time in seconds
          /// @param initial_delay in seconds
          StereoRingBuffer::StereoRingBuffer(float max_time, float initial_delay, int _sample_rate)
              : sample_rate{_sample_rate},
          m_buffers{*new std::vector<float>(max_time * (float)sample_rate, 0)},
          m_crossfade_buffer(CROSSFADE_SIZE, 0),
          m_write{(int)(initial_delay * (float)sample_rate)},
                m_buffer_size{(int)m_buffers.size() - 1},
              m_actual_size{(float)m_write}
          {}
          
          void StereoRingBuffer::reset(float max_time, float initial_delay, int _sample_rate) {
            sample_rate = _sample_rate;
            m_write = (int)(initial_delay * (float)sample_rate);
            m_actual_size = (float)m_write;

You fixed something similar in ring_buffer already.

The problem with Sinensis is here:

github.com

Ericxgao/NOI-VCVRACK/blob/65f0a099783c5afeb6b7c16d4ba88a8428f4aec1/src/Sinensis.cpp#L10-L11


      
          	float frequence, Q, numberOfBand, ratio;
          	float freq_cv;

These are uninitialized floats, so their value will be whatever happened to be in that memory location when the module is instantiated.

The oneinFour divider only writes their values every 4th time process() is called. So the first three times, their random/uninitialized values are read.
In particular it was crashing here:

github.com

Ericxgao/NOI-VCVRACK/blob/65f0a099783c5afeb6b7c16d4ba88a8428f4aec1/src/Sinensis.cpp#L147


      
          					if (thisBandFreq > 15000.F) { thisBandFreq = 15000.f - (thisBandFreq - 15000.f); }
          					if (thisBandFreq < 30.f) { thisBandFreq = 30.f + (30.f - thisBandFreq); }
          				}
          				//setParam only compute if params are different
          				bpf[i].setParam(thisBandFreq, Q);
          			}
          		}
          		
          		//process filter each clock ticks
          		output = 0;
          		for (int i = 0; i < numberOfBand; i++) {
          			float j = static_cast<float> (i);
          			if (numberOfBand - j < 1) {
          				output += (bpf[i].process(input) / numberOfBand) * (numberOfBand - j);
          			}
          			else {
          				output += bpf[i].process(input) / (numberOfBand);
          			}
          		}
          	
          		// set output

Randomly, sometimes numberOfBand is some huge number and this eventually tries to access memory out of range. I saw this attempt at memory access earlier but mistakenly thought it was because Pruners had left the heap full.