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.
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?
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,
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).
@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?
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.
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~ :)
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")
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)
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.
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.
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.
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.