sigmund~ 64-bit version

    Jun 30 2015 | 6:31 pm
    i had a go on making a 64-bit version of sigmund~ (for mac). if you want to try it out, go here all the best, vb

    • Jul 10 2015 | 11:49 pm
      i don't use max in 64-bit mode, but great job! i'm surprised this hasn't gotten more attention.
    • Jul 11 2015 | 7:52 am
      Oooh, will have a download!
    • Jul 11 2015 | 2:48 pm
      hi volker! great! would you mind to share your sources ( for sigmund and all your vb. stuff ) so i could try to compile for Win platform too?
      thanks and all the best
    • Jul 11 2015 | 6:56 pm
      Working nicely here.
      Out of curiosity, why did you change the name of it? (sigmund64~)
    • Jul 13 2015 | 2:43 pm
      @rodrigo good to hear that. i did change the name to be able to compare to the original carefully. then i thought that others might like to do the same, before replacing the old object. if everything is fine and i don't hear of any problems, i can change the name back.
      @alfonso sigmund~ source is now included. --> my other externals: i didn't care much for platform compatibility, so i shamelessly used a lot of vector functions from apple's vDSP lib. this makes porting really difficult for a lot of those objects. if there is interest in windows versions, i can happily pass on the code (of those objects where i think it should be reasonably easy to port) to someone who is willing to do the work, has experience in writing externals and in compiling on windows machines. are you the one, alfonso?
    • Jul 13 2015 | 3:09 pm
      I see. That makes sense. Was just thinking that having the same name would make it a drop in replacement without having to go back and edit a bunch of patches.
      Alfonso made the 64bit windows version of karma~, so that was super appreciated!
    • Jul 13 2015 | 5:03 pm
      @volker I'm a newbie in external coding but i did compiled some OSX stuff for Win recently. I can try to port your stuff either.
    • Jul 15 2015 | 7:39 pm
      thanks for your offer, alfonso. i'm thinking about putting some of my stuff on github. actually i've just taken the opportunity to come back to a long standing plan and started using it. oh, i love the summer, when you suddenly have a little time to move on with your own stuff - next to all the other things that need/want to be done... i'll post back in this space as soon as i have something going on github. all the best, vb
    • Jul 18 2015 | 8:38 am
      a pleasure volker. looking ffwd to your github repository! bests and have a good summertime!
    • Aug 24 2015 | 9:57 am
      hi, in the meantime the new 64-bit sigmund~ can be found here:
      right now, there are two releases: the first one is based on version v0.05 of the original sigmund~ sources, with only minimal changes to make it work in 64-bit mode. this is the same version that Ted Apel used to compile the old sigmund~ version (32-bit) for maxmsp. this should pretty much be a drop in replacement. the other release is based on v0.07, which never got compiled for maxmsp, afaik. Miller Puckette made some tweaks to the code after the original maxmsp port was done. so it might not behave exactly the same as the old maxmsp-sigmund~ version in all situations. also, this release has a complete 64-bit signal path (which shouldn't change things dramatically). please let me know if you run into problems.
      i'm also hosting some other projects at github now, and eventually plan to add more of my vb-objects (if i find the time).
    • Aug 24 2015 | 10:01 am
    • Aug 24 2015 | 11:00 am
      great! gonna try a compile for Win32/64
    • Aug 24 2015 | 11:02 am
      @Alfonso, you're like the Robin hood of compilation! (If 'the rich' = 64bit Mac externals, and 'the poor' = 32/64bit Win externals)
    • Aug 24 2015 | 1:36 pm
      @RODRIGO :-D :-D down deep in da sherwood forest for a quick walk while escaping from the sheriff i compiled sigmund~, slice~ and markov from the Volker githube repository. should i upload externals and .vcxproj files there? or here?
    • Sep 01 2015 | 2:27 pm
      great, alfonso! personally I don't have any use for the windows versions, but if you like, you can send them to me offlist [*], so i can bundle them up into one of the releases on github. I have forked a project by nao tokui, to make some changes to his slice~ object, but i haven't done anything to markov. by the way, I have just fixed one small bug in sigmund~ (in master), so now processing in the external should be properly stopped, when inside a muted poly~ subpatch. maybe you can recompile before making the windows version available. thanks, vb
      [*] you can find my email here
    • Sep 01 2015 | 2:52 pm
      Hi Volker, i've just recompiled with latest sources and sent you a zip with Win32/64 versions.
      "personally I don’t have any use for the windows versions, but if you like, you can send them to me offlist [*], so i can bundle them up into one of the releases on github"
      join me in da sherwood forest :-) and help me give poor win users the fruits of your work!
    • Nov 29 2015 | 10:08 am
      Volker, thank you very much for your 64 Bit port of sigmund~ !! Is there a way to get the same data out of sigmund~ as if it was fiddle~ with a specific setting? In 32 Bit Max I always used fiddle~ to get the pitch of my violin (microphone), which worked very stable, even if there was some cross-talk of my live-electronics in the analysed signal. Sadly fiddle~ is not yet ported to 64 Bit. That's why I tried to replace it with sigmund~. On the first sight this shouldn't be any problem, but unfortunately I get different results. I used fiddle with these settings: fiddle~ 2048 1 20 1 window size 2048, 1 pitch outlet, 20 peaks to find, 1 peaks to output I used the 3rd outlet (list: voice of continuous pitch and amplitude) and the 4th outlet (overall amplitude). This is super stable. With sigmund~ I tried the following settings: sigmund~ @npts 2048 @hop 1024 @npeak 20 peaks env I use the 1st outlet (continuos pitch) and the 2nd (env) Unfortunately I get unstable (in fact maybe more accurat) results. There are many jumps in the (midi-)output, even if I play a clear tone (with harmonic spectrum).
      Has someone maybe found a sigmund~ setting which gives a stable output in such situations? (I use filter/noisegate/gain beforhand to prepare the signal as good as possible.) Thank you!
    • Dec 02 2015 | 7:13 pm
      i haven't had a closer look at fiddle~, yet but i wouldn't be surprised if you can't get the same results, as i believe there are substantial differences between the two externals. but why don't you try the "pitch" argument (as shown in the help file)? e.g. [sigmund~ @npts 2048 @hop 1024 pitch env]
    • Dec 02 2015 | 10:27 pm
      Thank you. I'm sorry, I made a mistake in my last post. The setting was exactly like your proposal. Later I tried with the 1st partial, but it wasn't better. It's too late for today, but maybe I record a small violin sample in the next days and provide a small patch here to show, what I mean. I really would appreciate a 64 Bit comeback of fiddle~ :)
    • Dec 06 2015 | 12:50 pm
      To stabilize the pitch output of sigmund~ I made a little javascript object, which "tracks" the output with a simple algorithm. A tolerance in midi pitch can be set. If the new input is in the tolerance range the "age" of the track is incremented and the value is send out the first outlet. If a value doesn't fit in the range the "age" is decremented and instead the last old value is output. Not before the "age" falls below the minAge, the deviant value is output. The tolerance can be set in Midi pitch ("tolInMidiPitch" message). "minAge" and "maxAge" are int parameters (messages). Defaults are: tolInMidiPitch = 1. minAge = -5 maxAge = 5 Maybe someone else has a benefit using and improving this. Of course it slows down reported tone changes, but the end result is much more stable to process. Bang resets the track (="New Track") "debug" can be set to true (only inside the javascript file) to see whenever a "New Track" will happen.
    • Dec 06 2015 | 2:06 pm
      Thank you, MVF. This is very useful ;-)
    • Dec 10 2015 | 1:10 pm
      I really would appreciate a 64 Bit comeback of fiddle~ :)
      i did it this morning... if someone wants to try it, compiled binaries for osx can be found here: sources are here:
    • Dec 11 2015 | 9:04 am
      Wow Volker! Thank you so much for your efforts! I'll try it briefly this weekend. Martin.
    • Dec 16 2015 | 12:49 pm
      thanks Volker! here's Windows version both 32 and 64 architecture. (just put the folder in the Package directory) Volker would you try a port of bonk~ to new 64bit standard? BTW fiddle~ beheaves strange under 108 Hz (it does not recognize pitch)
    • Dec 20 2015 | 10:24 am
      hi alfonso - thanks for the win builts! i included them in the .zip file download. fiddle~'s capability to track low frequencies is limited by the provided fft size (and the sampling rate). with fft size 1024 and sr 44100, you can't go lower than 108 Hz, with sr 88200, this limit even goes up an octave and so on. that's the way fiddle~ works, and i have no plans to dig deeper in the code and try to improve things. i haven't used bonk~ a lot, and just had a peek at the source code. it seems it's not as easy to update as e.g. fiddle~. if i find some time over christmas, i will be working at it a little.
    • Jan 03 2016 | 1:30 pm
      ok, here is a 64 bit version of bonk~ compiled for osx. who ever needs it, please try it out and report back. sources on gitHub thanks, vb.
    • Jan 03 2016 | 1:52 pm
      Hi Volker! great! tried to compile on Win and i have the following
      Warning 1 bonk~ warning C4068: unknown pragma 254 1 Warning 2 bonk~ warning C4013: 'snprintf' undefined; assuming extern returning int 1288 1 Warning 3 bonk~ warning C4068: unknown pragma 1316 1 Warning 4 bonk~ warning C4068: unknown pragma 1449 1 Error 5 bonk~ error C2375: 'main' : redefinition; different linkage 1454 1
    • Jan 03 2016 | 1:59 pm
      oh..and here is slice~ for win 32 and 64... what about your vb. suite? any sources to try Win compilation? thanks!
    • Jan 03 2016 | 2:48 pm
      Warning 1 bonk~ warning C4068: unknown pragma 254 1 Warning 2 bonk~ warning C4013: ‘snprintf’ undefined; assuming extern returning int 1288 1 Warning 3 bonk~ warning C4068: unknown pragma 1316 1 Warning 4 bonk~ warning C4068: unknown pragma 1449 1 Error 5 bonk~ error C2375: ‘main’ : redefinition; different linkage 1454 1
      you can ignore the pragma warnings, or better comment them out. these are preprocessor directives that i use to organize the code. something between different versions of xcode changed - i think they stopped supporting those in recent versions. snprintf goes back to Miller's code, and is very similar to sprintf. if you google it, you shouldn't have difficulties replacing it. not sure about 'main' redefinition error. you can try to comment out the function declaration in the prototypes (line 268) and see if that works.
    • Jan 03 2016 | 2:51 pm
      oh..and here is slice~ for win 32 and 64…
      thanks for that. i added them to the zip files on my site.
      what about your vb. suite? any sources to try Win compilation?
      what i have right now is all on gitHub.
    • Jan 04 2016 | 1:32 pm
      hi all! here's bonk~ for Win32/64. thanks volker! bests
    • Feb 17 2016 | 1:02 pm
      since i haven't heard back about any problems, i made releases for all three objects - including the win versions by alfonso - on github now. you can find them here:
      all the best, volker.
    • Feb 17 2016 | 1:37 pm
      Thanks to both of you!
      Really great having all this stuff 64bit'd.
    • Mar 11 2016 | 10:54 pm
      This is great work. Any chance of a 64-bit (Windows) version of analyzer~?
    • Mar 20 2016 | 4:35 pm
      @TO_THE_SUN analyzer~ is part of CNMAT's collection, maybe ask them about it. on their site it says: "Full support for 64-bit Max 6.1 is coming soon. Please note that analyzer~, pitch~, loudness~, and brightness~ have been intentionally left out of this release. They will reappear in a subsequent release." don't know when that was posted, but it looks like someone is taking care of it.
    • Mar 20 2016 | 5:37 pm
      Actually since posting this I discovered the Package Manager and the fact that zsa.descriptors can be found there, in 32 and 64-bit. That has more than satisfied my needs.
    • Mar 24 2016 | 8:02 pm
      What would be really amazing would be a Windows version of this machine learning external (:D) And yes I am aware of Wekinator, but as a separate standalone program it has a number of encumbrances inherent to it.
    • Feb 11 2019 | 1:12 pm
      Thank you for these!
    • May 09 2021 | 8:59 am
      Hello all. [sigmund~] is still one of the best externals out there for analysis-resynthesis: any chance of a tweak to make a signed version for macOS Catalina and above? I know that there's a Terminal workaround (I used it) and that there's also zsa.freqpeak~, but tbh I prefer sigmund~ and would love a version that can be installed with the workaround.
    • May 09 2021 | 4:29 pm
      Hi, no need of workaround. Find the sigmund~ (or better sigmund64~) obj in Finder, then right click on the obj and "Open with Max". Answer open (or yes, my sistem is in italian) to the quarantine question. That's all! Just one time. Mac os Catalina 10.15.7, Max 8.1.11
    • May 10 2021 | 5:12 pm
      Cheers! Thanks for the suggestion, Riccardo. It's one I knew about already, but it's more that when I share my patches with other musicians, I'd like a system that doesn't even need this additional step for the end user. It's no biggie - just a "would be nice" thing :-)
    • May 10 2021 | 5:15 pm
      I would imagine this will be the case for most small/esoteric externals, as having the stuff be signed requires having a developer account (which costs money annually), so unless someone has a dev account already, it's unlikely they will create one in order to have signed externals.
    • May 10 2021 | 5:28 pm
      Ah ok, I haven't considered this issue. But nowadays I guess musicians on MacOsx have continuously to deal with small plugins unsigned, so perhaps the trick is quite common...
    • May 10 2021 | 5:35 pm
      I've run into problems with this with less experienced users and students, but fortunately it's a relatively easy fix. In the main, I avoid externals wherever I can, but [sigmund~] is just too good to pass up :-) If anyone knows how to do the job as well using vanilla MSP or gen~, I'd love to hear about it.
    • May 10 2021 | 5:56 pm
      Hehe, it's gone full circle, where you used to have a long file explaining what to do when you download a patch and put everything where it needs to be, to now needing a long file explaining what to do when you download and patch and put everything where it needs to be :)
      It's still an external, but I've moved most of my pitch analysis over to `fluid.pitch~` from the flucoma tools. The Yin algorithm, in particular, is really quite good. You don't get the partials and stuff like you can get out of `sigmund~`, but for vanilla pitch tracking I find the flucoma version to work quite well.
    • May 11 2021 | 8:10 am
      Ha! Hilarious :-) But we have one *really* nice improvement: when students prepare work for us, their being able to save it as a project to submit means we no longer have to deal with incomplete patchers and writing long emails to tell them how to find everything that they used in their patches - that's a Godsend :-)
      Thanks for the info about fluid.pitch~: I haven't looked at Flucoma yet - I'll check it out.
    • May 11 2021 | 9:24 am
      + 1 for projects being life changing. Though you do then have to them how to include everything in a project...
    • Jan 13 2022 | 3:51 pm
      Hi @Volker Böhm ! It seems sigmund~ doesn’t work anymore with silicon processors… Do you plan to make something to fix this issue ? Thanks a lot for your great work btw !
    • Jan 13 2022 | 4:01 pm
    • Jan 13 2022 | 4:09 pm
      Nice ! Thanks @Rodrigo !