@jameslo As [vline~] is involved then the scheduling could be correct even as the control is at control rate.
Not doing much audio work in Pd I hadn't realised that [sigmund~] exports midi notes rather than frequency.... thanks for spotting and pointing that out....!
It explains the non-linearity..... fm = 2((m−69)/12))*440 where fm is the frequency of the midi note m.
That is..... frequency = 2 (to the power of (m minus 69) divided by 12) times 440.
But the pitch as a frequency relative to time is a simpler calculation..... and remains linear as above.
An upper harmonic is more likely... note 96 (about 2000Hz) is well within range for [sigmund~] which struggles at very low frequencies.
As you say, the array will reveal all....... and the patch especially as it will show whether [vline~] is controlled correctly for scheduling.
I hope the whiskey was a good one.
David.
For @murkrellr ........

But of course if you have an array that reports a different midi note in [sigmund~] for a metro interval of 1 then you can replace the "40" with that value in your calculation.

And....... in this case...... the frequency(Hz) = interval/1000/12.135 (ish).
Taking the reported midi value value for the 0.1 interval matches the series better so.....
Frequency (Hz) = 83.3 / metro value

@murkrellr Well, for what it's worth, here are my whiskey-soaked observations on this very dead USA good Friday evening:

As others have been telling you, metro's speed is set by specifying the period (i.e. time between bangs, in mS). So if you think of each bang as a new "cycle", that's mS/cycle. But frequency is often specified in cycles per second, i.e. cycles/S. So at the very least there's a factor of 1000 in there somewhere, and the fraction is flipped upside down, i.e. raised to the -1 power.

OK, let's ignore the factor of a 1000 for the time being because I have no idea what your patch is doing and I can see that between 0.1 and 0.2, the MIDI pitch goes down an octave, i.e. goes down by 12. That means [ftom] has to be involved somehow. So my first guess is that there's probably some multiplicative factor also involved. How might one guess what it is?

Idea: take your value for 0.1, compute what that factor would have to be, and see if it works for any other values. Looks like it's 83.3012.

period to pitch function.pd
OK, so it looks like it works for all the values you provided except for 0.01, so I'm wondering if sigmund is giving you the wrong answer for that input, or maybe sigmund is latching on to some strong upper harmonic. It's hard to say without seeing the patch.

PS: was there any precalculus in any of that?

@ddw_music said:

@gentleclockdivider said:

So when I have two separate messages 1 0 1000 , and 0 0 1000 , both messages will wait for 1000 ms and have the exact same behaviour as when clicking the toggles ( see screenshot )

Do you want the envelope segments to run at the same time?

No. You want one after the other.

Therefore the two times should not be the same.

Making them both 1000 means it will of course not work.

Putting two messages into one message is afaik separated by a comma , this just does not work

It absolutely does work. Here, there's one message box with two messages in it, and you clearly see two envelope segments being drawn.

hjh
Now change that delay time time for the attack stage to 1000 , it won't work anymore

@gentleclockdivider said:

So when I have two separate messages 1 0 1000 , and 0 0 1000 , both messages will wait for 1000 ms and have the exact same behaviour as when clicking the toggles ( see screenshot )

Do you want the envelope segments to run at the same time?

No. You want one after the other.

Therefore the two times should not be the same.

Making them both 1000 means it will of course not work.

Putting two messages into one message is afaik separated by a comma , this just does not work

It absolutely does work. Here, there's one message box with two messages in it, and you clearly see two envelope segments being drawn.

hjh

@ddw_music said:

@gentleclockdivider said:

The issue is when I want to bring these two messages into a single one , which uses a comma sign "," ' to separate the two series of arguments
So 1 500 0; 0 600 0 but the message doesn't work becasue of the zero delay time in the first part of the message ( attack stage )

The message box should be 1 500, 0 600 500.

You misinterpreted "delay time" as the delay after the previous segment. In fact, it's a delay time after the moment of receipt.

If you want the "0 600" segment to execute immediately after the 500 ms segment, this is 500 ms after the message arrives at the inlet -- so you have to restate the 500.

You could argue that this not the way you would like it to be done, but this is what's documented and it does work.

hjh

If I put the nr's 1 0 1000 into a pack f f f and bang it , the vline will be executed 1000 ms after it has received it's trigger .
Same as when put in a message 1 0 1000
So when I have two separate messages 1 0 1000 , and 0 0 1000 , both messages will wait for 1000 ms and have the exact same behaviour as when clicking the toggles ( see screenshot )
Putting two messages into one message is afaik separated by a comma , this just does not work

@gentleclockdivider said:

The issue is when I want to bring these two messages into a single one , which uses a comma sign "," ' to separate the two series of arguments
So 1 500 0; 0 600 0 but the message doesn't work becasue of the zero delay time in the first part of the message ( attack stage )

The message box should be 1 500, 0 600 500.

You misinterpreted "delay time" as the delay after the previous segment. In fact, it's a delay time after the moment of receipt.

If you want the "0 600" segment to execute immediately after the 500 ms segment, this is 500 ms after the message arrives at the inlet -- so you have to restate the 500.

You could argue that this not the way you would like it to be done, but this is what's documented and it does work.

hjh

hey thanks alot for that. i just got it sorta working. i didnt realize you could do it with sigmund. i was thinking that only did like monophonic pitch tracking and id have to use the fft object or something, but sigmund can track about 16 partials. which is good enough for now, i can always split incoming signal into more bands and add more sigmund objects if i need to. way easier than i expected.

@atux OK, the number following the /curve path looks like it's the segment ID, so that's how you distinguish between the upper/lower traces. I'm not sure where the type mismatch is coming from, but the expected types are specified in the [unpack] arguments. In the same way that the segment ID is typed as a symbol ("s") I wonder if any of those zeros are also typed unusually? I also wonder if the [2] in front of "error" gives any hints? (I don't know Purr Data)

Now it works fine, both for triggers and for curves and cursors.
One question: using curves in IanniX, for example this bifurcation made of two different curves, the horizontal segment + the ascending segment has ID 3; the descending branch has ID 4:

in puredata how do i get both branches in output?
If I convert to sound in Purr Data (sine wave oscillator), I can hear the horizontal segment and then only the descending branch. In general, how can I "sort" the data of all overlapping curves the cursor encounters, so that I can then hear the sound of them all?
Maybe I need to add something to [unpack s f f f f f f]...

This is the current patch:

Thanks,
a.

@Nullstrahler said:

@bocanegra said:

You can get the latest .deb files from debians website: https://packages.debian.org/search?keywords=puredata but that means you gotta figure out dependencies yourself

Thanks. That is where problems start, as I do not understand exactly what this means or how to do this.

I went over it some 6 months ago in another thread: https://forum.pdpatchrepo.info/topic/13499/couldn-t-create-sigmund/2

Basically, you download all the packages named puredata something and run them with software center / synaptic or whatever

" cd path/to/pd'

"path/to/pd" is a generic placeholder and is meant ot be substituted with the actual path you installed pd to

If there was any hints regarding the installation of pd 51-4 or some clearance where I am on the wrong path I still would be interested.

THANKS!

See the thread I linked to above. Otherwise there are repositories you can add manually: https://puredata.info/docs/faq/debian - the debian stable repo should work (same packages I am running on xubuntu 20.04)

Adding apt.puredata.info manually
You can either add this line to the bottom of /etc/apt/sources.list Or you can add it in the GUI administration program Synaptic (in the Settings -> Repositories menu, then the Third-Party Software tab). Choose the line for your version of Debian or Ubuntu from the options below:

#Debian/stable
deb http://apt.puredata.info/releases stable main

After adding this repo and doing sudo apt update you should be able to install puredata 51.4 with apt install