Thanks for your replies.

@Maelstorm
I had a look at x_list.c and at sigmund~.c as sigmund sends out lists. I adapted code from sigmund and it works.

I inserted t_atom at[2]; in the struct and replaced line 30 outlet_float... with:

SETFLOAT(x->at, (t_float)max[0]);
SETFLOAT(x->at + 1, (t_float)max[1]);
outlet_list(x->f_out, 0, 2, x->at );

Can you tell me, why your second argument is &s_list whereas in sigmund its just 0?

@Pierre
What is the advantage to send the message by a clock over doing it with an outlet?

And thanks for your tip. The HowTo says they should, but in the code, the method isn't used.
see HowTo
That was confusing me anyway.

I have a DSP chain. It begins with pitch tracking with sigmund~ and then a series of abstractions follow that have a switch~ in each, controlled by polygate~ output (i.e. once I switch off an abstraction in the chain, polygate~ sends a zero to switch~ in that abstraction. Vice versa. It works well.

The problem. When I load the patch and switch~ on the 6 instances of sigmund~ (which is generally CPU heavy in itself, but I have never had a problem with it until now) the CPU rises to around 90%, whereas before redesign of the chain (I've replaced a few abstractions which may be a little more CPU intensive, but not much), the CPU was barely over 50%.

The weird thing. When I switch ON the rest of the DSP chain, the CPU drops to 70% (which is where I would expect it to be).

My question(s). What the hell is going on? Why is sigmund~ wetting the bed before the rest of the chain is on? Is my computer having a crisis?

Cheers,

Ricky

p.s. Abstractions are not in parent patch.

Hello everybody:
Finally I solved the issue of using fiddle~ with switch~, which caused Pd to crash. The idea of using switch was to use fiddle~ just as needed. As Katjav proposed (read the previous posts), I turned to sigmund~ instead of fiddle~. This brought a new advantage: sigmund~ can wait for a number of samples until the next calculus of frequency, so there is no need for an additional metro and switch~ control. Just using the output as a bang to the calculus worked just fine.
The abstraction is set to calculate the pitch every 0.19s, more or less, when using 44100Hz of samplerate. Higher sample rates would make this output rate decrease.
Yes, I could have used sigmund~ right away to calculate the midi pitch and then calculate just the cents and that could have made the abstraction less cpu consuming. I will leave it to others to improve it, as it took me more time than I thought to make it work (I'm quite new to Pd). Ten instances of this abstraction just connected to the phasor~ on the test patch I attach gave 3% of cpu usage (as read on htop, text based Debian utility for cpu processes monitoring). I hope it works well with smaller computers too.
I also added a datum in the packed output that gives the error percentage in the frequency calculus. I did not test it on vocals or instruments yet, just osc~ and phasor~.
Well, I hope this could be useful to someone. Thanks to everyone who contributed.

Sumidero.

http://www.pdpatchrepo.info/hurleur/testNoteNames-sumidero-V3.zip

Heeyaaa,

I've been playing with [sigmund~] for some hours to discover it's 'special mojo', and I must thank Lead for his advice.
Now I know that [sigmund~] is more efficient than [fiddle~]. So I could replace one by the other and the result was so much better that my first 'filtering' idea becomes much less urgent.

Here is a test bench for this audio to midi conversion. Five instances of [sigmund~] are paralleled so you can switch from one to another and hear the 'accuracy' of the operation. It also uses what I would call 'the [poly 1 1] trick' that replaces manual noteoff handling as infinite notes must be avoided. (found in this forum)

The parameters you'll find in the first instance of [sigmund~] work rather well when I play violin live. But for testing purposes a 'not so in-tune not so dynamic not so precise violin sample' can be sent to the bench and gives a reference for the tests.

I was surprised by the fact that a rather good pitch recognition can be achieved with 'hop' and 'npts' sizes theorically too small for the lowest frequency to be found . And thus was surprised to be able to lower latency more than expected ! Flirting with Shannon's limit ?!

Just open audio2midi_testbench.pd and then the [essai_sigmund_flow] object that lies in it.

To be continued ...

Nau

After looking at this (and your videos) and thinking about it more, I'm not so into using [sigmund~] anymore. Because it only works at message rate, I don't think it's well suited for resynthesis. I think it could be done with FFT, but I can't wrap my head around how to do it with live input (I'm not well-versed in FFT anyway), which is what I think you want to do in the end.

But I think you'll be okay with band-pass filters, unless there's something bigger here your trying to achieve that requires strictly sinusoids. I do have some recommendations, though, for how to improve your patch a bit.

First, I think you should switch to [vcf~]. You can control the center frequency at audio rate, and if you intend on doing any bends, you'll likely want that.

To go along with that, I don't think it's necessary to use _out of [sigmund~]. (In fact, the way you have it now, if your guitar is slightly flat, it will truncate to the half-step below. It should actually be [+ .5]->_if you're looking to "autotune.") Doing that kills some important guitar idiosyncrasies, like bends and vibrato. You might be better off instead using the non-integer MIDI note like this:

[sigmund~]
|
[mtof]
|
[vline~]
|
[lop~ 4]
| [r partial.number]
| /
[*~ ]
\
\
[vcf~]

Obviously you'd rework that a bit to fit in your patch, but I think you get the idea.

To pull frequencies out instead of isolate them, you'll want a notch filter. This is just a reverse band-pass filter, really, so you could make one like this:

[inlet~]
| \
| [vcf~]
| |
[-~ ]
|

Also keep in mind that [sigmund~]'s output is delayed by the hop size, so you should delay the copy of the input signal going into the filters by that amount if you want the filters to line up perfectly with the notes. Well, it won't be perfectly, but "closer to perfectly."

One last thing, instruments like guitars have noisy attacks, which can result in initial erratic pitches coming out of pitch trackers. There are two things that can help with this. One is to low-pass filter the signal going into [sigmund~] to keep the output from being to high (Some pitch trackers actually work better if you get rid of some unnecessary high-frequency content. Not sure about [sigmund~], though). The other thing is to get a running median of the output of [sigmund~]. This essentially has the effect of throwing out any outliers. You can use [median_n] from mapping to do this. You may find you'll need to delay the signal a bit more for this to be accurate, though. Probably by hopsize*median_n arg/2.

Hope that helps.__

PD is new to me and I could need some help to get it to do what I want.
My attached patch is a part of a patch where a sphere is transformed in respons to incoming sound. This part currently increases the number of segments in the sphere to a maximum of 20 and then start over again counting from 0.
Instead of just jumping from 20 to 0 segments I want the procedure to go backwards -- to decrease instead of increase the number of segments -- until it hits 0.
I've tried to do this myself, but just ended up being frustrated.
Can anyone help me to sort this basic PD control structures out? How could this be done?

Thanks in advance!

http://www.pdpatchrepo.info/hurleur/rotate_part.pd

I want to remove them all and reinstall , but in root terminal it report me 0 files has been removed .

so I removed all the pd folder in terminal

after that I reinstalled the extended-intrepid version . but
when I run in terminal , a report shows here:

priority 98 scheduling enabled.
sh: /usr/local/bin/pd-watchdog: not found
priority 96 scheduling enabled.
sh: /usr/local/bin/pd-gui: not found

and I think that because I removed pd-0.40.2 folder which I compiled before.

and then I'm searching from google ,that the files which we compiled that should be install and removed by checkinstall.

so I downloaded the package and installed in terminal .

but checkinstall failed ..

report is here :

checkinstall 1.6.1, Copyright 2002 Felipe Eduardo Sanchez Diaz Duran
This software is released under the GNU GPL.

The package documentation directory ./doc-pak does not exist.
Should I create a default set of package docs? [y]: y

Preparing package documentation...OK

*** No known documentation files were found. The new package
*** won't include a documentation directory.

*****************************************
**** Debian package creation selected ***
*****************************************

This package will be built according to these values:

0 - Maintainer: [ root@mal ]
1 - Summary: [ pd description ]
2 - Name: [ src ]
3 - Version: [ ]
4 - Release: [ 1 ]
5 - License: [ GPL ]
6 - Group: [ checkinstall ]
7 - Architecture: [ i386 ]
8 - Source location: [ src ]
9 - Alternate source location: [ ]
10 - Requires: [ ]
11 - Provides: [ src ]

Enter a number to change any of them or press ENTER to continue:

Installing with make install...

========================= Installation results ===========================
cd ../obj; cc -Wl,-export-dynamic -o ../bin/pd g_canvas.o g_graph.o g_text.o g_rtext.o g_array.o g_template.o g_io.o g_scalar.o g_traversal.o g_guiconnect.o g_readwrite.o g_editor.o g_all_guis.o g_bang.o g_hdial.o g_hslider.o g_mycanvas.o g_numbox.o g_toggle.o g_vdial.o g_vslider.o g_vumeter.o m_pd.o m_class.o m_obj.o m_atom.o m_memory.o m_binbuf.o m_conf.o m_glob.o m_sched.o s_main.o s_inter.o s_file.o s_print.o s_loader.o s_path.o s_entry.o s_audio.o s_midi.o d_ugen.o d_ctl.o d_arithmetic.o d_osc.o d_filter.o d_dac.o d_misc.o d_math.o d_fft.o d_array.o d_global.o d_delay.o d_resample.o x_arithmetic.o x_connective.o x_interface.o x_midi.o x_misc.o x_time.o x_acoustics.o x_net.o x_qlist.o x_gui.o x_list.o d_soundfile.o s_midi_oss.o s_audio_oss.o d_fft_mayer.o d_fftroutine.o \
-ldl -lm -lpthread
cc -g -O2 -DPD -Wall -W -Wstrict-prototypes -Wno-unused -Wno-parentheses -Wno-switch -DDL_OPEN -DPA_USE_OSS -DUNIX -DUNISTD -DUSEAPI_OSS -I../portaudio/pa_common -I../portaudio/pablio -I../portmidi/pm_common -I../portmidi/pm_linux -fno-strict-aliasing -O6 -funroll-loops -fomit-frame-pointer -D_LARGEFILE64_SOURCE -o ../bin/pd-watchdog s_watchdog.c
cc -g -O2 -DPD -Wall -W -Wstrict-prototypes -Wno-unused -Wno-parentheses -Wno-switch -DDL_OPEN -DPA_USE_OSS -DUNIX -DUNISTD -DUSEAPI_OSS -I../portaudio/pa_common -I../portaudio/pablio -I../portmidi/pm_common -I../portmidi/pm_linux -fno-strict-aliasing -O6 -funroll-loops -fomit-frame-pointer -D_LARGEFILE64_SOURCE -o ../bin/pdsend u_pdsend.c
cd ../extra/bonk~;make
make[1]: Entering directory `/home/mal/Documents/pd-0.40-2/extra/bonk~'
make[1]: Nothing to be done for `current'.
make[1]: Leaving directory `/home/mal/Documents/pd-0.40-2/extra/bonk~'
cd ../extra/choice;make
make[1]: Entering directory `/home/mal/Documents/pd-0.40-2/extra/choice'
make[1]: Nothing to be done for `current'.
make[1]: Leaving directory `/home/mal/Documents/pd-0.40-2/extra/choice'
cd ../extra/expr~;make
make[1]: Entering directory `/home/mal/Documents/pd-0.40-2/extra/expr~'
make[1]: Nothing to be done for `current'.
make[1]: Leaving directory `/home/mal/Documents/pd-0.40-2/extra/expr~'
cd ../extra/fiddle~;make
make[1]: Entering directory `/home/mal/Documents/pd-0.40-2/extra/fiddle~'
make[1]: Nothing to be done for `current'.
make[1]: Leaving directory `/home/mal/Documents/pd-0.40-2/extra/fiddle~'
cd ../extra/loop~;make
make[1]: Entering directory `/home/mal/Documents/pd-0.40-2/extra/loop~'
make[1]: Nothing to be done for `current'.
make[1]: Leaving directory `/home/mal/Documents/pd-0.40-2/extra/loop~'
cd ../extra/lrshift~;make
make[1]: Entering directory `/home/mal/Documents/pd-0.40-2/extra/lrshift~'
make[1]: Nothing to be done for `current'.
make[1]: Leaving directory `/home/mal/Documents/pd-0.40-2/extra/lrshift~'
cd ../extra/pique;make
make[1]: Entering directory `/home/mal/Documents/pd-0.40-2/extra/pique'
make[1]: Nothing to be done for `current'.
make[1]: Leaving directory `/home/mal/Documents/pd-0.40-2/extra/pique'
cd ../extra/sigmund~;make
make[1]: Entering directory `/home/mal/Documents/pd-0.40-2/extra/sigmund~'
make[1]: Nothing to be done for `current'.
make[1]: Leaving directory `/home/mal/Documents/pd-0.40-2/extra/sigmund~'
install -d /usr/local/lib/pd/bin
install: cannot create directory `/usr/local/lib/pd': No such file or directory
make: *** [install] Error 1

**** Installation failed. Aborting package creation.

Cleaning up...OK

Bye.

root@mal:/home/mal/Documents/pd-0.40-2/src#

I dont know what to do now ....

yeah something to take a file cut it into segments and allow me to control how the segments are played back
i'm sure you've heard of recycle right?

[vd~] will be your friend for this one. first, you'll have to specify how long the segment you want to play back in reverse is, for you oviously can't reverse something continuously. then you need a vd~ initially at twice the delay time that the length of your reverse segment. now we'll take a line~ to fade the length of the vd~ from (2 x segment length) to 0, within the length of a segment. you can loop this behaviour to get a more or less continuing effect, but beware that the reverse-delay rhythm has to hit your musical rhythm in some way, for otherwise it would sound queer

stn

i'm looking for a free solution too. i don't think my original idea is going to work out because i don't have the time to implement it. maybe some of you have ideas for the problem i am trying to solve.

the problem is this:
i am helping a professor with some research. for his research he is doing a case study on 3 composers. he is asking them to record a narrative of there thoughts on the composition process as they compose. for this, the composers will be working an a mac studio workstation putting the composition together in logic. a second computer, a pc , running audacity will be used to record there sounds. when the composer reaches what they consider a significant change in the program, we are asking them to save their project to a new file (so we end up with a series of files showing the various stages of the composition). we would like a way, however, to map the timestamps of those files to the 'timeline' of their narrative.

here are a few solutions that are not exactly desirable:
a. do not stop the recording at all and make a note of what time the recording started. this means that you can calculate what time speech is taking place by adding the number of minutes and seconds (and hours) to the time at which the recording started. the problem with this is that it will yield very large files which are not very practical, especially considering that we have to transcribe these files.

b. have the composers start each segment of narration with a timestamp: "it is now 9:15 on tuesday...." as part of the research methodology, this creates problems with the flow of a more natural narrative of the compositional process.

c. have the composers save each segment of narration as a seperate time-stamped file. the problem here is that this takes more time, and could create a lot of files that would be very annoying to work with when it comes to transcribing.

c. my idea was to have, instead of just input from the microphone, 2 streams of audio input,one on the left channel and one on the right channel. on the left, would be the recorded narrative. on the right, would be an audio signal that encodes a time stamp. i was think of simply convert a number such as DDMMHHMM (day, month, hour, minute) into DTMF tones. these could then be translated back into a timestamp. an 8-tone dtmf sequence would be generated every 10 seconds or so. this way, as long as the narrative segment was longer than 10 seconds, it would contain a timestamp. the problem with this is that i have no way to mix such a signal with the input from the microphone.

any suggestions would be greatly appreciated. thanks.