sigmund~ 64-bit version
i had a go on making a 64-bit version of sigmund~ (for mac).
if you want to try it out, go here http://vboehm.net/2015/06/a-64-bit-version-of-sigmund/
all the best,
vb
i don't use max in 64-bit mode, but great job! i'm surprised this hasn't gotten more attention.
Oooh, will have a download!
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
Working nicely here.
Out of curiosity, why did you change the name of it? (sigmund64~)
@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?
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!
@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.
best!
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
a pleasure volker.
looking ffwd to your github repository!
bests and have a good summertime!
hi, in the meantime the new 64-bit sigmund~ can be found here:https://github.com/v7b1/sigmund_64bit-version/releases
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).
Wonderful!
great!
gonna try a compile for Win32/64
@Alfonso, you're like the Robin hood of compilation!
(If 'the rich' = 64bit Mac externals, and 'the poor' = 32/64bit Win externals)
@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?
bests
a.
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 http://vboehm.net/about/
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!
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!
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]
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~ :)
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.
Thank you, MVF. This is very useful ;-)
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:http://vboehm.net/downloads/
sources are here:https://github.com/v7b1/fiddle_64bit_version
Wow Volker! Thank you so much for your efforts!
I'll try it briefly this weekend. Martin.
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.
ok, here is a 64 bit version of bonk~ compiled for osx.
who ever needs it, please try it out and report back.http://vboehm.net/downloads/
sources on gitHub
thanks, vb.
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
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.
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.https://github.com/v7b1/vb-objects
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:
sigmund~https://github.com/v7b1/sigmund_64bit-version/releasesfiddle~https://github.com/v7b1/fiddle_64bit_version/releasesbonk~https://github.com/v7b1/bonk_64bit-version/releases
all the best,
volker.
Thanks to both of you!
Really great having all this stuff 64bit'd.
This is great work. Any chance of a 64-bit (Windows) version of analyzer~?
@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.
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.
What would be really amazing would be a Windows version of this machine learning external (:D)
https://github.com/cmuartfab/ml-lib/releases
And yes I am aware of Wekinator, but as a separate standalone program it has a number of encumbrances inherent to it.
Thank you for these!
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.
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
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 :-)
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.
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...
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.
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.
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.
+ 1 for projects being life changing. Though you do then have to them how to include everything in a project...
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 !
Nice ! Thanks @Rodrigo !