Digital to audio processing issues
@Joseph-Mikkelson No, changing the samplerate will not help, except that matching it to the soundcard reduces the load on the cpu......but there are more important issues...... see below.....
I should have expanded on latency.
Using a live input [adc~] and doing some Pd processing effects and then sending that to speakers [dac~] latency is not so much of a problem. Often it involves delays anyway (echo, reverb, etc.) and our ears are used to that.
Latency for playback of an audio track, or generated audio, is no problem...... it is heard when it arrives at the speakers and that is all.
Problems arise when the input goes straight to the output....... as with a monitor mixer built in Pd for example..... with live acoustic instruments...... where the musician hears their own instrument acoustically and the same sound delayed in the monitor. Essentially a chorus effect is produced, caused by the latency, and that will make it harder for a violinist for example to pitch correctly.
Chorus in a reverb effect really upsets violinists..... anything much over 5ms.
Of course a massive latency...... 100ms+..... will cause timing problems even for a guitarist, and even if they are the rare musician that didn't have such issues in the first place.
I have met classical and jazz musicians that have learnt to dissociate what they play from what they hear...... for example playing through a delay, but in sync with everyone else...... so playing say 1 second before everyone else....... but......
SAMPLE RATE
You should match your samplerate to your soundcard, or you will have re-sampling artefacts....... usually a low level high pitched whine when your patch is not producing any sound.
It is slightly more complicated than that.
If you play an audio file that was recorded at 44.1KHz while the Pd samplerate is set to 48KHz it will play back at the wrong speed....... Pd will not resample it and so the pitch will be wrong.
It's a PITA.
So the Pd samplerate must be set to match all the audio files that you use in Pd.
To avoid the artefacts you then need to set your soundcard to match Pd.
Other programs will adjust..... so that is not a problem.
External cards can make that change through their control panel, and internal cards should have the option somewhere.
In windows it is here in the speaker control panel..... https://forum.pdpatchrepo.info/topic/12094/newbie-clipping-on-pure-data-portable-with-mmio/4
and I am pretty sure that windows always sets the on-board soundcard to 48KHz "out of the box".
David.
Problem bypassing a filter in pd-extended
Hi!
I'm starting to learn Pd Extended and I trying to make a filter able to highpass, lowpass, both things or neither of them, but I'm having problems making a toggle to bypass the filters:
While in the highpass filter everything works fine (I can move the slider to the frequency I want, I can turn it off and I can turn it on again keeping the frequency I chose before), when I try to do the same on the lowpass filter, everytime I turn the toggle off (as a bypass), I stop hearing the sound.
Here is my configuration and my patch:
Thank you in advice!
i/o-errors in pd
I come from here: https://forum.pdpatchrepo.info/topic/9461/record-audio-of-any-length-into-array/8
Then, searching more about sound clicks and interruptions I've found this thread so I will continue here.
I'm dealing with the exact same problem as you, especially when resizing tables, which is crucial for dealing with samples and loops in realtime audio processing applications like you said. As far as I know, Pure data was designed in a way that array modifications and object calculations are done in the same thread the audio is flowing, so it's impossible to separate them and audio will be always interrupted. So, after looking for pure data distributions and externals, I've found something that maybe solve part of this problem, the sndfiler external, which is included in the last pd-l2ork distribution:
https://github.com/pd-l2ork/pd/tree/master/externals/tb/sndfiler
FEATURES:
- threaded reading of multichannel soundfiles into arrays
- threaded resize of arrays
I've installed the latest pd-l2ork distribution in windows and the sndfiler isn't installed by default, but it appears in the source code, so I will have to try building it from the source code if nobody has the built external. It also needs libsndfile and libvorbisfile and threadlib external in pd, a little bit complicated but may solve the problem.
For the GUI updating problem, you may solve it by separating the main GUI and the sound processing in differents patches. I've been doing this separation since I started using pd and never run into dsp problems.
Filtering out one of two instruments (that are both playing the same note)
Hi everyone,
I've run into an interesting problem with a iPhone rhythm game project I'm working on:
Basically the game has a scrolling score of music that you can play with your instrument at the same time. My patch detects pitches in real-time and then marks notes on the screen as correct or not.
The problem is that there is a built-in guide synth that plays each note as it scrolls (this is toggleable however). Right now I'm having the problem of the built-in guide synth scoring notes correctly without the user providing any input.
Obviously this issue goes away once the user wears headphones, but when you are playing audio on the phone's speaker at anywhere above 50% volume notes will get triggered automatically no matter what. I have tried several techniques (noise gate, some filters, minpower settings on helmholtz~ and sigmund~) that reduce the problem but not eliminate it.
That being said, I'm not hoping to completely eliminate this problem 100% (because it's most likely not possible), but I was wondering if anyone had any suggestions for kinds of techniques that could differentiate a real-life instrument from this built-in synth playing on the iPhone speaker, where both instruments are playing the same note?
Thank you
PD-PROCESSING with OSC problems
Hi guys! i am trying to connect Pure Data and Processing by OSC. Yesterday when i did the conection between the two programs it was succesfull. But today, i get this problem:
i am working with the port 11112, If i open pd first ,and then run the processing sketch i get this message of processing:
"ERROR @ UdpServer.start() IOException, couldnt create new DatagramSocket @ port 11112 java.net.BindException: Address already in use: Cannot bind"
If i open processing first and then pure data, processing listening the port 11112 without any problem,but the error in pure data that i get is:
" dumpOSC 11112
... couldn't create",
if, for example i write dumpOSC 11111 (and processing stills in 11112), the dumpOSC object
is created normally.
I think is a UDP problem but i cant find the solution anywhere, Please, does anybody know what the problem is? THANKS!!
i/o-errors in pd
@EsGeh You should not be having these problems. At all. Except "resizing a table".
Even that should not cause a problem if it is hidden in a sub-patch and you are not reading from it as you resize.
I can run a 64ch in 64ch out mixer controlled by osc messaging from 64 tablets in Pd, at 3ms latency without a glitch (Extended on Windows7)
Are you running Pd at the same samplerate as your soundcard?
Are you trying for too small a buffer to improve latency?
Have you given Pd root priority (chmod 4755)?
Could you post some more detail..... os, soundcard, Pd version?
Chapter 2.5 ........ https://puredata.info/docs/manuals/pd/x2.htm/?searchterm=i/o error
explains what Pd gets up to, and why it is best to hide unused gui's, and there is more help on that site.
You can run more than one instance of Pd and communicate between them through ports, and that will sprout 2 instances of wish, which spreads the gui load as well. Whether your OS will run them all in the same processor I don't know. Recent OS's should automatically spread them about.
I have had problems trying to control a gui through more than 2 levels of gop.
If you wish to post a problem patch then we can see if it works well on our systems, which might narrow it down.
David.
Clipping problem with line and a synth subpatch?
I'm trying to make a keyboard-controlled synthesizer that uses one sample by changing the speed at which the sample is read, and in order to avoid the lower notes being longer than the higher notes, I wanted to implement a decay function. I sent how long the decay was in the main patch, then received the length in the main subpatch. However, now whenever the decay time is not 0, when I press more than one or two notes at once, crazy clipping and speed problems occur, slowing down and amplifying everything until it is unintelligible.
I think the problem might be originating in how I am using my $1 for the length of the decay line, or it could be overloading the output of my subpatch by including all 12 of my synth modules. Can anyone help me with this? I have attached the program (main program is called "slendro attempt") and the files involved in my problem.
little help: emulating a physical spring, ex. bend-wheel
First to @weightless and @ingox : thank you, for the great work on this.
Very cool! And I very much appreciate how promptly you solved the problem.
Am very sorry to say on the other hand, I did not state the problem as accurately and succinctly as I should have.
To the problem, as stated, the solution is perfect.
The problem, stated more directly (not doing the abstracting in the writing of the use-case (common pd-forum user-problem?)):
"I want to be able to add a slider to Mobmuplat (MMP) and have it self-center like a bend-wheel/tremolo-bar, and then send its resultant value over LAN as an OSC signal to my laptop with pd on it. And MMP is vanilla-only. (So no iem-guts.)"
Note: the wonderful, iOS app, "Syntien" (an OSC-gui design tool) has a property on its slider like this, "return to center". (Only handheld-app I have ever bought).
(I'll double check the above...) Yes. The above scenario is correct.
Seems such a control, would prove useful to not only me, but a wider audience. (Maybe?)
p.s. I approached the above problem by placing aerially-speaking "drag" on the slider, so incrementally it subtracted from the slider value then sent it back into the slider. The result was stack-overflows.
Any ideas on this front would be great.
Thanks, again, for the effort put into the solution of the original use-case.
Please, accept my apologies for not having been more forthcoming to begin with.
Sincerely,
Scott
Sysex program dump with random zeros
Okay ;that's what I suspected you were doing. It is possible to use the MTP serial directly with linux and the mtpav driver, though this requires a machine with true hardware parallel port access (USB adapters won't cut it) and is limited to MIDI output only as the driver is a hack that was never finished. I used to run mine that way with a second USB MIDI interface connected to one or more of the MTP's unused routed MIDI outputs (there is, BTW still no way to connect the MTP USB version directly to a Linux system as it doesn't use a standard USB MIDI driver)
As far as the kernel is concerned, I've only ever used lowlatency or RT kernels for MIDI stuff. I don't know how a generic kernel would affect this problem but it's probably best avoided as they are not specifically built for multimedia.
Now read closely as this is where it becomes stupidly complicated.
First, make sure that the problem is internal to Pd. Your interfaces are probably not the issue (since Pd is only seeing the UM-1 driver I don't think the MTP even figures in here). However, the chosen MIDI API can get in the way, specifically in the case of the unfinished JACK MIDI. JACK MIDI presently can only pass SYSEX as short realtime messages. SYSEX data dumps will disappear if sent into the current JACK MIDI system. ALSA works OK. OSS probably too, but I have not tried it.
If that stuff is ruled out and you are still getting problems, it probably has to do with a set of longstanding bugs/oversights in the Pd MIDI stack that can affect the input, output, or both.
On the output side there is a sysex transmission bug which affects all versions of Pd Vanilla before 0.48. The patch that fixed Vanilla had already been applied to L20rk/PurrData for some time (years, I think). The output bug did not completely disable SYSEX output. What it did was to miss-format SYSEX in a way that can't be understood by most modern midi applications, including the standard USB MIDI driver software (SYSEX output from Pd is ignored and the driver/interface will not transmit anything). You would not notice this bug with a computer connected directly to an MTP because the MAC and Linux MTP drivers are programmed to pass raw unformatted MIDI.
If this is the problem and you have to use a pre-0.48 version of Vanilla it can be patched. See:
https://sourceforge.net/p/pure-data/bugs/1272/
On the MIDI input side of Pd we have 2 common problems. One is the (annoyingly unfinished but nevertheless implemented) input to output timestamping buffer that's supposed to provide sample-accurate MIDI at the output (if it was finished). This can be minimized with the proper startup flags (for a MIDI-only instance of Pd, -rt -noaudio -audiobuf 1 -sleepgrain 0.5 works for me) or completely defeated with a source code tweak to the s_midi.c file. This may not be the source of your particular problem as it usually only affects the time it takes to pass messages from input to output, but is worth mentioning as it can be very annoying regardless.
With SYSEX dumps it is more likely that the problem lies with the MIDI queue size. This is very common and I experienced it myself when trying to dump memory from a Korg Electribe Ea-1.. The current version of Pd limits the queue to a size of 512 (even worse it used to be 20) and any input larger than that will get truncated w/no error warning. There is not yet any way to change this with startup flags or user settings. This can only be "fixed" by a different tweak to s_midi.c and recompiling the app.
The attached text files are derived from the Pd-list and will show the specific mods that need to be made to s_midi.c.
Sound problems of Patches that moved from Windows 10 to Raspbian
Hello,
I've been making guitar effects with Puredata and Raspberry Pi.
Previously I did not care much about this problem, but at the last moment I got a terrible problem so I would like to consult with you.
I created Puredata Patches on Windows 10, copy Patches to Raspbian and use it.
In most cases there is no problem,
but depending on the Patches the sound reproducibility will be different.
Please help if there is a solution,thank you.
Windows_And_Raspbian.mp4
test.pd
*I uploaded same files in Google Drive and Dropbox.
1)There is a problem with the reproducibility of the sound, especially the problem is remarkable with the decay sound.
2)The problem is reproduced even if Windows 10 and Raspbian use the same USB Audio interface(Behringer UCG102)
3)Even if I use a different USB Audio interface (Zoom U - 22) in Raspbian, the problem is reproduced.