volker böhm

fiddle~, bonk~ and sigmund~ are three classic objects originally written by Miller Puckette for Pure Data. They have been ported to MaxMSP early on and were incorporated into many patches ever since. Who wants to try (or continue) to use them on a recent system running MaxMSP or M4L, can find new 64-bit versions of the objects here:

https://github.com/v7b1/fiddle_64bit_version/releases

https://github.com/v7b1/bonk_64bit-version/releases

https://github.com/v7b1/sigmund_64bit-version/releases

fiddle~https://github.com/v7b1/fiddle_64bit_version/releasesbonk~https://github.com/v7b1/bonk_64bit-version/releasessigmund~https://github.com/v7b1/sigmund_64bit-version/releases

64-bit-versions-of-sigmund-fiddle-and-bonk

Thank you for tanking the time to make bonk for us :)

I have a problem that when I make a bonk node and turn on DSP; Max crashes.

Ignore me... I should probably check that I've the right output device selected first.

Maybe someone with powers can delete my 2 posts?

I use the sigmund~ object is several Max programs on my Macintosh. When I upgraded from Max 6 to Max 7 I noticed a problem: after 30 seconds to 3 minutes of running a patch, sigmund~ would “lock up” and stop outputting data. The only fix was to turn the DSP off and back on. I downloaded Volker Böhm’s 64-but version in July (2016), which improved performance, but did not eliminate the problem entirely. With Max 7.2.4 on a Macbook pro (OS 10.10.5), sigmund~ runs smoothly as long as I am using the built-in Mac audio i/o. But when I add an external interface (Native Instruments Complete Audio 6) the lock-up occurs from time to time and I must pulse the DSP off for 10ms to restore — not the best solution when running continuous audio output. Using mute~ to switch off a subpatch containing only sigmund~ does not help, only a full DSP off/on clears the jam. My NI drivers for the interface are up-to-date, I will test with a different interface as soon as I can borrow one.

To recap: sigmund~ is solid with Max 6, unreliable with Max 7, even after the Böhm 64-bit upgrade. Has anyone else experienced similar problems or have suggestions? Thanks. NC

I use the sigmund~ object is several Max programs on my Macintosh.  When I upgraded from Max 6 to Max 7 I noticed a problem: after 30 seconds to 3 minutes of running a patch, sigmund~ would “lock up” and stop outputting data.  The only fix was to turn the DSP off and back on.  I downloaded Volker Böhm’s 64-but version in July (2016), which  improved performance, but did not eliminate the problem entirely.  With Max 7.2.4 on a Macbook pro (OS 10.10.5), sigmund~ runs smoothly as long as I am using the built-in Mac audio i/o.  But when I add an external interface (Native Instruments Complete Audio 6) the lock-up occurs from time to time and I must pulse the DSP off for 10ms to restore — not the best solution when running continuous audio output.  Using mute~ to switch off a subpatch containing only sigmund~ does not help, only a full DSP off/on clears the jam.  My NI drivers for the interface are up-to-date, I will test with a different interface as soon as I can borrow one.

To recap: sigmund~ is solid with Max 6, unreliable with Max 7, even after the Böhm 64-bit upgrade.  Has anyone else experienced similar problems or have suggestions?  Thanks.  NC


From some testing last year prepping for a gig, there's a memory leak in the 64bit version.

Is there any progress on this? I use sigmund~ all the time, but run my patch in Max 6. I think it's about time I started using 7 (at least for a bit before 8 comes out)! I dimly remember having issues with this before, which I'm guessing was down to the memory leak Rodrigo mentions..

comments like "it does not work" are useless! and also "there's a memory leak" is not helpful, without knowing a little bit more about how and under which circumstances this was observed.

so if you would like to use the object(s) but encounter issues, please do your homework, try to isolate the problem and report back as precisely as possible what's happening on your side.

Hi there,
comments like "it does not work" are useless! and also "there's a memory leak" is not helpful, without knowing a little bit more about how and under which circumstances this was observed.
so if you would like to use the object(s) but encounter issues, please do your homework, try to isolate the problem and report back as precisely as possible what's happening on your side.
otherwise nothing is going to be fixed.
vb


Thanks so much, Volker, for creating the 64-bit version of sigmund~.

Being a sigmund~ user, I was hoping that the following info gives a leeway into solving the problem of the object grinding to a halt. I tested in both Sierra, as well as High Sierra on my MacBook pro - late 2013. I found out that there is no problem when running in Max in Core Audio, using the built in microphone and built in output. The problem starts when using an audio interface (in my case a Motu UltraLite Hybrid mk3, connected either via firewire/thunderbolt or via usb). sigmund~ stops working consistently after ca. 8 minutes and some seconds and it resumes after switching off and on the dsp. However, if the driver in Max is set to ‘ad_portaudio Core Audio’ the problem disappears completely and I can keep running my patches more than 48 hours (which I tried literally) without any interruption. It seems the problem is caused by Core Audio as such. There are comparable issues. The interruption after ca. 8 minutes and a bit also happens using spat.yin~. The snapshot~ object also grinds to a halt after running a patch for a couple of hours (I avoid using it these days and replace it with peakamp~).

Is this info useful? Meanwhile I am happily running all my patches, selecting the driver mentioned above.

Thanks so much, Volker, for creating the 64-bit version of sigmund~. 

thanks for the report, josz. unfortunately I can't help here, since from inside an external object, we can't access anything that relates to the chosen audio drivers. What is passed into an external object are simply audio vectors for reading/writing sample data. this is something that cycling would have to look into.

Not having access to such an audio interface, I can't screen the problem myself, either.

I'll keep an eye/ear on this UltraLite Hybrid problem, though.

thanks for the report, josz. unfortunately I can't help here, since from inside an external object, we can't access anything that relates to the chosen audio drivers. What is passed into an external object are simply audio vectors for reading/writing sample data. this is something that cycling would have to look into.
Not having access to such an audio interface, I can't screen the problem myself, either.
I'll keep an eye/ear on this UltraLite Hybrid problem, though.
vb


I want to try this one but the link is not working on my device. but some of my friend told me that it is absolutely working on their device. I don't have any other alternate device to check that the issue is on my device or the link is expired. If the issue is on my device then <a href="https://hpsupports.co/hp-support-assistant/">hp customer service</a> will definitely help me to solve that issue. So if you check first that the link is expired or not then it will be helpful to me.

I want to try this one but the link is not working on my device. but some of my friend told me that it is absolutely working on their device. I don't have any other alternate device to check that the issue is on my device or the link is expired. If the issue is on my device then  <a href="https://hpsupports.co/hp-support-assistant/">hp customer service</a>  will definitely help me to solve that issue. So if you check first that the link is expired or not then it will be helpful to me.

in MAX7.3.5 Windows 10 just creating a unique object [fiddle~] max window reports: "Out of memory". 

Again, 
in MAX7.3.5 Windows 10 just creating a unique object [fiddle~] max window reports: "Out of memory". 
Any help is very appreciated.
stefano


The "out of memory" message is a little misleading, but fiddle~ needs to be instantiated with some sensible arguments (I think I fixed this some time ago for the mac version).

The "out of memory" message is a little misleading, but fiddle~ needs to be instantiated with some sensible arguments (I think I fixed this some time ago for the mac version).
please consult the help patch. 



Thank you very much for answering,
it works with proper args!
best

I'm trying to get 64 bit fiddle~ object to run in my "Voices" patcher in Max8, on macOS Ventura 13.5.2.

I had this running 6 months ago but lost it. I'm trying to get it going again, but now in my 90th year I can't remember what I did.

I downloaded your fiddle~.mxo, and fiddle~.mxe64, and put fiddle~.mxo in the externals folder.

I will appreciate very much having your help.

Dear  Volker Böhm,
I'm trying to get 64 bit fiddle~ object to run in my "Voices" patcher in Max8, on macOS Ventura 13.5.2.
I had this running 6 months ago but lost it. I'm trying to get it going  again, but now in my 90th year I can't remember what I did.
I downloaded your fiddle~.mxo,  and fiddle~.mxe64, and put fiddle~.mxo in the externals folder.
/Applications/Max.app/Contents/Resources/C74/externals
What to do with the fiddle~.mxe64 doc?
I will appreciate very much having your help.
Thanks,
-John



Dear John, what an honour to have you here!

The fiddle~ object comes in the format of a ‘max package’. You can simply move the whole folder ‘fiddle_64bit_version’ to the following location:

I wish you all the best and good health for the coming years!

Hope that works for you.
I wish you all the best and good health for the coming years!
Volker

64-bit versions of sigmund~, fiddle~ and bonk~