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.

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

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

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.

pd_midi_io_timing_buffer_mod

pd_midi_input_quere_mod

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.

Google Drive

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.

@NoDSP It all works fine on Windows. OSX I have not heard of problems since Pd addressed them in 2011. Ubuntu, some problems after 16.04 (and sometimes before... but X-window). Generally a lot of Linux font problems on Google.
Sorry I am not helping with your particular problem.
You could try a.... sudo apt-get install --reinstall x-ttcidfont-conf ttf-dejavu....... if not done so already.
I am having trouble understanding why it should be a tcl issue when it works fine on other Linux distros.
Tk 8.4 was a problem..... but it's very old now......
But Pd will need a re-write (again) just for newer Linux. I don't know what other problems that will throw up for system compatibility. There was a long debate about it last time.
David.

@johnwbyrd I have never looked at the source code, but I run a live performance with Pd....... 30 input channels, 8 out..... with live mixing and using [readsf~] for up to 15 minute backing tracks, and I have never had Pd hang even momentarily.
I use extended for that although I doubt the [readsf~] implementation is different.
However, I use windows7....... and is it possible that Pd and the OS treat disk access slightly differently on other systems? I doubt that.

[readsf~] requires an "open" and a "start"...... so it is not forward looking as it might be in an audio editor. However if you program the "open" in advance.... or even at load, then the start is instantaneous (in ram) and you can emulate an instant player.
If Pd is stumbling during playback..... look elsewhere for the problem....... not in [readsf~]......

A multi-GHz processor with rapid disc access should not have problems with audio or Pd...... they use a paltry fraction of the resources available.

Yes..... Pd prioritises audio..... like all programs that use audio.... over video, screen drawing...... everything. So if your patch is struggling in any way you could see the Pd gui stumble.
Check thoroughly your audio and latency settings.... any mismatch with the capabilities of the soundcard could cause what you are seeing.
More here about setting up your computer for audio......... https://forum.pdpatchrepo.info/topic/10125/audio-and-video-why-do-i-have-problems ..... with a link to a good read for problem solving!
You often just need to tell your OS to do as instructed......"and I mean it!"........... Otherwise it prefers to go and peruse it's Facebook page for likes!

Maybe, otherwise, use FL studio or something similar.
Programs written specifically for audio application will have been written in assembly language and be more appropriate for your purposes.
Communication with Pd is usually facilitated through at least midi or OSC messaging.
David.

i updated the original post. The current version is now stable even without the virtual mouse click.

The problem was, that to drag the whole plotted array, the click has to go to the invisible grabbing area of the element, which represents the variable y. In the first version, when this area was missed, the click would not grab the element and dragging wouldn't work. The virtual mouse click solved this, because it would always click at the center of the element where the grabbing area is located.

The current version doesn't need the virtual click anymore, because it moves the whole struct on click, so that the grabbing area of the element is moved to where the mouse is. After it got the click, it is moved back to the original position.

The drawback is, that it is not always accurate while dragging (the virtual click solution has the same problem). The further you click away from the center of a slider, the more inaccurate it becomes. i am still looking for a solution for this.

i also made another version, which uses pixel dragging instead of the plotted array drawing feature:

multislider-pixel.pd

Now this way it is always accurate, but because it is processed through Pd and not directly working on the data structure, it will miss some sliders if you move the mouse fast. This is the effect you also get if you use an external to get the mouse position and set the sliders from there.

Hello,

I created a new thread as the older post [Problem compiling on windows] (http://forum.pdpatchrepo.info/topic/967/problem-compiling-external-on-windows/16) seems to have ended and my problem has a different nature.
Moreover. I have not been able to find an answer on the puredata sites (puredata.info or puredata.org).

My problem:

My end goal is to play with the 'grid' external in pd-extended/externals/unauthorized/grid but since I do not get this one working and I have never compiled an external before I started with the simpler tutorials in Pd/doc/6.externs.

My steps and error are as follows:
**1. **Adap path in 'makefile' in Pd/doc/6.externs to 'C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC'
(this path contains a /lib folder with .lib and .obj files on my machine)
**2. **Start ( Admin) Visual C++ 2008 64-bit command prompt
**3. **Locate directory Pd/doc/6.externs
**4. ** run 'nmake pd_nt' command
**5. ** gives error in locating the libc.lib file
(LINK: fatal error LNK1181: cannot open input file 'C:...\VC\lib\libc.lib'

When I remove this instruction from the makefile, I does not find the kernel32.lib file also.
When I finally remove the former instruction, I get an error creating the library obj1,lib and object obj1,exp as I have 6 unresolved external symbols ex. obj1.ob : error LNK2019: unresolved external symbol __imp_post referenced in function obj1_float

Could someone help me solve these issues and help me succeed in making this external work?
Then, any additional explanation in getting grid to work afterwards?

Any additional info regarding Pd's treatment of externals/libraries etc is appreciated as well.. I just can't get a grip on it,

Hello all,

I finally had time to clean up and release my collection of abstractions called 2D Virtual Acousmonium. Its purpose is to use reacTIVision to track a listener wearing wireless headphones inside a physical space and to use his position and angle to compute the loudness and direction of virtual sounds, effectively immersing him in a virtual space. But some people using reacTIVision for other purposes may find some of this useful.

For more info, see: https://github.com/gilbertohasnofb/2D-virtual-acousmonium/

Cheers,
Gilberto