Definitely something strange going on here with MODwatcher. I did another version of the waveguide plugin that hasn’t got any audio input for triggering but includes an impulse generator inside the same patch for resonating the waveguide. Everything works in Max but as soon as I build the plugin for MOD nothing comes out. I guess the overload happens instantly when the plugin is loaded. The plugin compiles without any errors but doesn’t work.
1 Like
I actually got the waveguide plugin working but it required adding some clippers in the signal path and also controllable feedback inside the loop with multipliers. The patch was working fine without these modifications in Max so something was changing the code and creating too much feedback in the plugin built with MODwatcher.
I’ll post some stuff with the waveguide at some point, not sure if there are other physical modelling percussion synths in the MOD platform.
2 Likes
What Max version are you running?
1 Like
The latest, 8.5.2.
1 Like
Just as an experiment, can you downgrade the Max version and try again?
I had some issues with it recently and their support suggested me to downgrade.
Let us know what are the results
1 Like
I’ll try with an older version soon. Which version would be a good one to try with?
I’m also facing another issue with gen~ patches that include the data object (a gen~ substitute for buffer~ object in Max). The data buffer seems to get stuck after some time and won’t record anything, just loops something that was recorded to it a while a go. This is in a patch that should be recording new stuff all the time and not repeat anything. Also this patch works fine in Max. Should I make a new topic for this issue or can we deal with it here?
1 Like
8.3.3
I can try to give you some help, but maybe the guys from Cycling74 would be the best to approach on that one.
1 Like
I can ask help from c74 for the problem with data objects but any help here would also be appreciated. Have you used data in your own MOD plugins and did it work as expected? I’d guess this could be a bug and not a mistake in my patch as things are working fine in Max.
3 Likes
I haven’t got time yet to build my plugins with a downgraded version of Max but I posted an Instagram clip with the waveguide model in action to the content exchange topic.
I’ll link it here as well:
4 Likes
I’ve just built the waveguide and time stretch plugins with Max 8.3.3. and I’m getting the same results as with Max 8.5.2. The waveguide has more feedback in the signal path than the same gen~ patch ran in Max and the time stretch stops recording new material after a few minutes, only loops what was recorded in the buffer before (not happening in Max).
I have no idea why the waveguide’s feedback is not the same but luckily I got the plugin working with some modifications. With my time stretch patch there seems to be something wrong how the data object (used as an audio buffer here) works in a plugin built with MODwatcher. It would be great to get this to work as there are no workarounds for using the data object. I’d say it’s quite a serious problem and limitation if plugins built with Max that utilize an audio buffer are not working.
EDIT: It’s also pretty strange that I’m seeing the data object as a knob in the exported plugin similarly to controls made with params in Max.
I recon this has more to do with the gen~ c++ export than the MOD wrapper.
The MOD (DPF) wrapper really just takes the generated DSP code and makes it interface as an audio plugin, but it doesn’t modify any of the DSP code.
Any differences in behavior should be specific to how gen~ does its code export.
While that can be what is happening, it doesnt really help much the case at hand.
Best would be to see if the issue is also present when exporting the max gen object in other formats, but I am not sure what is possible at the moment (not too well versed in Max things myself)
The data-object seen as a parameter is “normal”, I have seen that behaviour before for other plugins that use delay lines. It can be safely ignored.
1 Like
Ok, good to know about the data object showing as a parameter. Unfortunately I don’t have any other devices I could export the code to and I can’t build anything with just the audio code myself. So testing this is a bit challenging.
I’m wondering if the audio code for the new MIRRORZ plugin was entirely built in Max. I’m pretty sure it has to use some kind of buffer for the reverse effect and most probably works fine.
1 Like
If you are ok with the plugin being open, I can easily add yours into the same project for testing.
In any case we need to reach out to Cycling 74 (MAX authors) as it is likely a bug in the gen~ exporter.
1 Like
Sure, the time stretch algorithm was floating in the c74 forums, I just ported the necessary parts to gen~ so there’s no reason why it shouldn’t be open.
What would be the best way and format to share my patch?
If you share the exported cpp/h files, rest is easy to handle to get a plugin out.
Or even the gen patch
I actually got some help at the c74 forum for this and got my time stretch patch working correctly.
This was happening because Max uses 64-bit and (probably) MOD uses 32-bit float. I was running the data object with a counter that wasn’t reset to 0 at any point and was just counting upwards. When the counter got up to 16,777,217 (32-bit upper limit) it would stop working and my data buffer would freeze. After adding a simple reset mechanism my plugin works as expected.
(This doesn’t of course resolve the difference in feedback amount between Max and MOD in my waveguide plugin.)
1 Like
I think only for the MOD Duo, the DuoX and Dwarf are 64 bit.
those are for cpu architecture. audio-wise all systems use 32bit audio internally.
3 Likes
ah I see. that would explain differences in behavior then.
1 Like