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


    Feb 17 2016 | 1:22 pm
    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:
    all the best, vb

    • Feb 17 2016 | 1:37 pm
      Many thanks Volker! all the best a.
    • Feb 17 2016 | 3:15 pm
      Thank You, Volker! :)
    • Sep 09 2016 | 10:11 pm
      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.
      Windows 7, Max 6, 64 bit.
    • Sep 09 2016 | 10:32 pm
      Ignore me... I should probably check that I've the right output device selected first.
      Maybe someone with powers can delete my 2 posts?
    • Sep 10 2016 | 2:52 pm
      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
    • Feb 12 2018 | 7:04 pm
      Hi there,
      It does not work on max 7.3.4 64bit.
    • Feb 12 2018 | 7:24 pm
      From some testing last year prepping for a gig, there's a memory leak in the 64bit version.
    • May 01 2018 | 11:59 am
      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..
    • May 04 2018 | 1:49 pm
      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
    • Sep 02 2018 | 10:00 am
      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 again for all the 64-bit stuff.
      JZ
    • Sep 04 2018 | 2:49 pm
      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
    • Mar 27 2020 | 12:16 pm
      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
    • Mar 27 2020 | 5:23 pm
      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.
    • Mar 27 2020 | 5:47 pm
      Thank you very much for answering, it works with proper args! best
      stefano