Hi all,

I needed to have some more long-running visualisation of waveforms in PD, so as there is no vanilla [scope~] object, I thought I'd use [tabwrite~] with [array], as commonly recommended - however, I have stumbled upon a somewhat strange behavior, which I'm not sure whether it's a bug. This is on Ubuntu 18.04, vanilla Puredata from Ubuntu repos (0.48.1-3)

So, basically I made a patch, which is mostly reused help of [tabwrite~] :

The patch itself is here: test-array-scopevis-metro.pd

So, basically, I want to view signals as if on a scope with timebase of 1 second. My PD/Media/Audio Settings tells me: Sample rate: 44100, Block size: 64, Delay (msec): 25

So, all I have in addition to what was there in the [tabwrite~] help, is a few objects to set the array98 array size to 44100 when the patch is loaded - so there is enough memory to record 1 second of signal. And then I've added a metro, so it bangs the tabwrite~ each second (each 1000 msec) - the idea being that I bang the tabwrite~, it records 44100 samples in a second and shows them, then after that second I bang again, it records 44100 samples in a second and shows them anew and so on - pretty much like an oscilloscope at a timebase of 1 sec would do.

However, the actual response is shown in this video:

test-array-scopevis-metro.ogv

That is, when I start the metro at 1000 msec, it keeps banging for at least 10 times, without the array ever refreshing the waveform display?! Then, when I stop the metro, the waveform is displayed ?! At that point, I draw whatever in the array graph so as to "reset" this display, change the metro to 1001 msec - and start the metro again. This time the display does update as expected - but only after an initial delay of some 2 seconds (or three bangs) - I would have otherwise expected a delay of 1 second (two bangs).

Does anyone knows why this happens, and how to get a more reliable behavior for this kind of case? My guess is, for a [metro 1000], PD actually does not have enough time to fill the entire array with all 44100 samples, and thus it never updates the graph - apparently 1 millisecond extra is enough for PD to realize that the array has been filled, and so it updates the graph, but then why does it take 2 sec (at 3rd bang) to update, and not only 1 second (at 2nd bang)?

Purr Data 2.3.1 is now available:

https://github.com/jonwwilkes/purr-data/releases/tag/2.3.1

Bug fixes in 2.3.1:

• fixed some display bugs in GUI
• fixed display bug with preset_hub
• fixed undefined behavior on x64 systems with the dollar arg parser
• strengthen the testing system

New in 2.3.0:

• added first draft of an external test suite to make sure a majority of external classes can load and instantiate correctly. Previously, the CI runners could register a "successful" build even if build errors kept one or more libraries from building correctly. Now there is a minimum number of objects that must instantiate in the tests or the build will fail. We can build on this to guarantee an exact number of creators for each library, making it much easier (and less risky) to imiprove the build system.
• ported tof/imagebang and allow it to instantiate with no arguments
• added "arch", "platform", and "libdir" methods to [pdinfo] and update help patch
• default loader now uses the "hexmunge" code to find filenames with hex encodings that accommodate object names with special characters

Bugfixes in 2.3.0:

• fixed up external arg types, use static declarations to protect against namespace pollution, fix allocation errors, fix crashers, header problems, fix buggy aliases for externals, fix some makefiles, fix various buffer overflows
• added missing help files for some external aliases (don't think they are used, but they are required by the Makefile)
• handle special case of trailing "/" or "/~" in legacy external alias classnames
• updated zexy, markex, iemmatrix alias files to use the simplified hexmunger
• removed external hexloader loader from default loaded libs now that we have rudimentary hexloading in the main loader
• removed arbitrary limit of 128 characters for classnames that are absolute paths
• fixed harmgen interface to use proper A_GIMME args
• fixed invalid reads in iemmatrix
• bump lyonpotpourri to head to fix missing object name argument
• make [declare -lib] handle absolute paths (and namespace-prefixed paths) consistent with object boxes
• removed references to helpers in fluid~ that got removed
• allow iemlib, unauthorized, lyonpotpourri iem_spec2, bin_ambi, iem_ambi, iem_adaptifilt and mrpeach objects to instantiate without arguments. Try to set sane defaults for these situations, while also outputting a warning. (Might consider changing the warning to an error...)
• allow class_addcreator to register an additional creator with the namespace prefix if one was used
• triage iem16's lack of shared lib with statically declared copy/pasta functions
• remove a bunch of state files from iem16 that somehow got added to the repo at the outset
• remove unnecessary pd files from fluid~
• make all cyclone classes instantiate when no arguments are provided
• switch lyonpotpourri submodule to gitlab mirror. This is needed to make some quick fixes found by the test system (which we can later request to merge upstream)

Report issues here:

https://git.purrdata.net/jwilkes/purr-data

Thanks for those links Monetus. I'm pretty close with my existing setup and will first try to work with that when I have some more time. Some of the output from the samples/cpp/pdtest appears to be as expected.

However, from main.cpp

    cout << endl << "BEGIN Patch Test" << endl;
    
    // open patch
    Patch patch = pd.openPatch("pd/test.pd", ".");
    cout << patch << endl;
    
    // close patch
    pd.closePatch(patch);
    cout << patch << endl;
    
    // open patch again
    patch = pd.openPatch(patch);
    cout << patch << endl;
    
    // process any received messages
    //
    // in a normal case (not a test like this), you would call this in
    // your application main loop
    pd.processFloat(1, inbuf, outbuf);
    pd.receiveMessages();
    
    cout << "FINISH Patch Test" << endl;

the response

BEGIN Patch Test
Patch: "pd/test.pd" $0: 1003 valid: 1
Patch: "pd/test.pd" $0: 0 valid: 0
Patch: "pd/test.pd" $0: 1005 valid: 1
PD: PATCH OPENED: 1003
print: 0
PD: PATCH OPENED: 1005
print: 0
FINISH Patch Test

seems right but no patch was opened and if I already opened that patch before running the executable, none of the print messages (called later in the code) showed up in the console of pd. I'll focus on this and try to repost to the forum when I have a better idea of what is going on.

Hi! I am running Pd-0.47-1-64bit on Mac OS 10.11.6 and libpd 0.9.2. I am trying to work with the samples/cpp/pdtest. Here's the github repo. I currently have an app that takes video and spits out a 2D array of color values for regions of interest to file. I have a pd patch that then loads those into a table and plays the corresponding pitch. I need the two (patch, c++ app) to coordinate the IPC.

I compiled the cpp code in the samples directory however, when running pdtest executable there is no patch opened. Is this by design? I was not able to find a pd-vanilla to build from source so took the most recent (pd-0.47-1-64bit.mac.tar.gz). Does libpd need to have the pd built after libpd? If so, can anyone please point me to a src file?

Here is a truncated output from running the compiled pdtest. Could someone tell me if this is what is expected?

Thank you for your help.

BEGIN Patch Test
Patch: "pd/test.pd" $0: 1003 valid: 1
Patch: "pd/test.pd" $0: 0 valid: 0
Patch: "pd/test.pd" $0: 1005 valid: 1
PD: PATCH OPENED: 1003
print: 0
PD: PATCH OPENED: 1005
print: 0
FINISH Patch Test

BEGIN Message Test
FINISH Message Test

BEGIN MIDI Test
FINISH MIDI Test

BEGIN Array Test
array1 len: 10
array1 0.0857145 0.328572 0.500001 0.57143 0.514287 0.47143 0.357144 0.285715 0.057143 0
array1 0 1 2 3 4 5 6 7 8 9
array1 10 10 10 10 10 10 10 10 10 10
FINISH Array Test

BEGIN PD Test
FINISH PD Test

Processing PD
PD: bang
PD: 100
PD: symbol test string
PD: bang
PD: 100
PD: symbol test string
PD: 1.23 a symbol
PD dollar zero: 1.23 a symbol
PD: 1.23 sent from a List object
PD: msg 1.23 sent from a List object
PD: 1.23 sent from a streamed list
PD MIDI: notein 2 60 64
PD MIDI: ctlin 2 0 64
PD MIDI: pgm 2 101
PD MIDI: midiin 1 239
PD: symbol test
PD: START MSG TEST
CPP: bang toCPP
CPP: float toCPP: 100
CPP: symbol toCPP: kaaa
CPP: list toCPP: 100 2.3 test 1 2 3 ffsfff
CPP: message toCPP: kaa 1 2.3 test ffs
PD: MSG TEST FINISH
PD: START MIDI TEST
PD: MIDI TEST FINISHED
PD: START ARRAY TEST
PD array1: 10
PD array1: 10
PD array1: 10
PD array1: 10
PD array1: 10
PD array1: 10
PD array1: 10
PD array1: 10
PD array1: 10
PD array1: 10
PD: FINISH ARRAY TEST
PD: test_abs: Hello World!
CPP MIDI: note on: 0 0 127
CPP MIDI: note on: 0 0 127
CPP MIDI: note on: 0 60 64
CPP MIDI: control change: 0 64 100
CPP MIDI: program change: 0 99
CPP MIDI: pitch bend: 0 2000
CPP MIDI: aftertouch: 0 100
CPP MIDI: poly aftertouch: 0 64 100
CPP MIDI: midi byte: 0 239
CPP: float env: 75.5457
CPP: float env: 87.9506
CPP: float env: 93.5842
...

CPP: float env: 88.5503
CPP: float env: 87.7612
print: 1
CPP MIDI: note on: 0 0 0
CPP MIDI: note on: 0 1 127
CPP: float env: 86.8932
...

CPP: float env: 41.2584
CPP: float env: 0
print: 2
CPP MIDI: note on: 0 1 0
CPP MIDI: note on: 0 2 127
...

print: 20
CPP MIDI: note on: 0 19 0
CPP MIDI: note on: 0 20 127

@whale-av - Just a quick update.
I'm familiar with the update/upgrade process, but not the other ones including upgrade-f.

But I ran the first step suggestion, update and upgrade-f, and it seemed to install fine. So I tried to restart before testing PD...

But my whole rpi doesn't work now. I'm running it with one of their 7" touch screens, but it just stops its booting up procedure at a point, and has only a flashing underscore style cursor in the top left hand of the screen.

I can type and press enter, but no commands are recognised. At this stage I'll re-boot the card with Wheezy, but prior to installing PD I'll do the update/upgrade and rpi-update and see if that helps!

I just installed Ubuntustudio 15.10 Wily Werewolf 32bit on a thinkpad and I am trying to upgrade PD to extend. I am fairly new to linux but it seems like the instructions on https://puredata.info/docs/faq/debian fails.

This is the log from executing the commands. Any suggestions and help will be appreciated

myuser@machine:~$  sudo add-apt-repository "deb http://apt.puredata.info/releases `lsb_release -c | awk '{print $2}'` main"[sudo] password for zoundart:
myuser@machine:~$ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-key 9f0fe587374bbe81
Executing: gpg --ignore-time-conflict --no-options --no-default-keyring --homedir /tmp/tmp.beJyKhm5Lr --no-auto-check-trustdb --trust-model always --keyring /etc/apt/trusted.gpg --primary-keyring /etc/apt/trusted.gpg --keyserver keyserver.ubuntu.com --recv-key 9f0fe587374bbe81
gpg: requesting key 374BBE81 from hkp server keyserver.ubuntu.com
gpg: key 374BBE81: "Hans-Christoph Steiner <hans@guardianproject.info>" not changed
gpg: Total number processed: 1
gpg:              unchanged: 1
myuser@machine:~$ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-key D63D3D09C39F5EEB
Executing: gpg --ignore-time-conflict --no-options --no-default-keyring --homedir /tmp/tmp.BDfXAe3l5j --no-auto-check-trustdb --trust-model always --keyring /etc/apt/trusted.gpg --primary-keyring /etc/apt/trusted.gpg --keyserver keyserver.ubuntu.com --recv-key D63D3D09C39F5EEB
gpg: requesting key C39F5EEB from hkp server keyserver.ubuntu.com
gpg: key C39F5EEB: "Launchpad Pure Data" not changed
gpg: Total number processed: 1
gpg:              unchanged: 1
myuser@machine:~$ sudo apt-get update
Hit http://no.archive.ubuntu.com wily InRelease
Get:1 http://no.archive.ubuntu.com wily-updates InRelease [64,4 kB]                                                               
Get:2 http://no.archive.ubuntu.com wily-backports InRelease [64,5 kB]                                                             
Get:3 http://security.ubuntu.com wily-security InRelease [64,4 kB]                              
Ign http://apt.puredata.info wily InRelease                                                                
Ign http://apt.puredata.info wily Release.gpg                                   
Ign http://apt.puredata.info wily Release                 
Get:4 http://security.ubuntu.com wily-security/main Sources [17,0 kB]     
Get:5 http://no.archive.ubuntu.com wily-updates/main Sources [24,1 kB]                     
Get:6 http://no.archive.ubuntu.com wily-updates/restricted Sources [3 741 B]               
Get:7 http://security.ubuntu.com wily-security/restricted Sources [2 854 B]                
Get:8 http://no.archive.ubuntu.com wily-updates/universe Sources [6 112 B]                 
Get:9 http://no.archive.ubuntu.com wily-updates/multiverse Sources [1 922 B]               
Get:10 http://security.ubuntu.com wily-security/universe Sources [3 691 B]                 
Get:11 http://no.archive.ubuntu.com wily-updates/main i386 Packages [59,3 kB]               
Get:12 http://no.archive.ubuntu.com wily-updates/restricted i386 Packages [13,4 kB]          
Get:13 http://security.ubuntu.com wily-security/multiverse Sources [1 922 B]
Get:14 http://no.archive.ubuntu.com wily-updates/universe i386 Packages [31,0 kB]           
Get:15 http://no.archive.ubuntu.com wily-updates/multiverse i386 Packages [6 052 B]
Get:16 http://security.ubuntu.com wily-security/main i386 Packages [43,4 kB]                 
Err http://apt.puredata.info wily/main i386 Packages                                         
  404  Not Found
Ign http://apt.puredata.info wily/main Translation-en_US             
Get:17 http://no.archive.ubuntu.com wily-backports/main Sources [750 B]
Get:18 http://security.ubuntu.com wily-security/restricted i386 Packages [10,8 kB]          
Get:19 http://no.archive.ubuntu.com wily-backports/restricted Sources [28 B]                 
Ign http://apt.puredata.info wily/main Translation-en                                              
Get:20 http://no.archive.ubuntu.com wily-backports/universe Sources [833 B]
Get:21 http://no.archive.ubuntu.com wily-backports/multiverse Sources [28 B]
Get:22 http://no.archive.ubuntu.com wily-backports/main i386 Packages [606 B]
Get:23 http://security.ubuntu.com wily-security/universe i386 Packages [24,8 kB]
Get:24 http://no.archive.ubuntu.com wily-backports/restricted i386 Packages [28 B]
Get:25 http://no.archive.ubuntu.com wily-backports/universe i386 Packages [714 B]
Get:26 http://security.ubuntu.com wily-security/multiverse i386 Packages [6 052 B]
Get:27 http://no.archive.ubuntu.com wily-backports/multiverse i386 Packages [28 B]
Hit http://no.archive.ubuntu.com wily-backports/multiverse Translation-en
Hit http://no.archive.ubuntu.com wily-backports/restricted Translation-en
Get:28 http://security.ubuntu.com wily-security/main Translation-en [23,2 kB]
Hit http://no.archive.ubuntu.com wily/main Sources               
Hit http://no.archive.ubuntu.com wily/restricted Sources     
Hit http://no.archive.ubuntu.com wily/universe Sources             
Get:29 http://security.ubuntu.com wily-security/multiverse Translation-en [2 536 B]
Hit http://no.archive.ubuntu.com wily/multiverse Sources                               
Hit http://no.archive.ubuntu.com wily/main i386 Packages                                         
Hit http://no.archive.ubuntu.com wily/restricted i386 Packages     
Hit http://no.archive.ubuntu.com wily/universe i386 Packages       
Get:30 http://security.ubuntu.com wily-security/restricted Translation-en [2 666 B]
Hit http://no.archive.ubuntu.com wily/multiverse i386 Packages                             
Hit http://no.archive.ubuntu.com wily/main Translation-en    
Hit http://no.archive.ubuntu.com wily/multiverse Translation-en  
Hit http://no.archive.ubuntu.com wily/restricted Translation-en  
Get:31 http://security.ubuntu.com wily-security/universe Translation-en [15,2 kB]
Hit http://no.archive.ubuntu.com wily/universe Translation-en                       
Hit http://no.archive.ubuntu.com wily-updates/main Translation-en        
Hit http://no.archive.ubuntu.com wily-updates/multiverse Translation-en
Hit http://no.archive.ubuntu.com wily-updates/restricted Translation-en
Hit http://no.archive.ubuntu.com wily-updates/universe Translation-en
Hit http://no.archive.ubuntu.com wily-backports/main Translation-en
Hit http://no.archive.ubuntu.com wily-backports/universe Translation-en
Fetched 496 kB in 7s (70,7 kB/s)                                                                                                  
W: Failed to fetch http://apt.puredata.info/releases/dists/wily/main/binary-i386/Packages  404  Not Found

E: Some index files failed to download. They have been ignored, or old ones used instead.
myuser@machine:~$ sudo apt-get install pd-extended
Reading package lists... Done
Building dependency tree      
Reading state information... Done
Package pd-extended is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'pd-extended' has no installation candidate

@whale-av said:

@jancsika There is absolutely nothing at all random about [random].......... every time you run it you get the same sequence (displaced if you seed it, and displaced if you have more than one instance)......... proof.........test-random.pd
Use the patch to start Pd (if you have random already open somewhere)...... i.e. please re-start Pd from scratch to run the patch..........
There are two tests........... the top bang (manual) shows the sequence.
The "Test" bang shows the second occurrence of the first sequence is at exactly 237343 bangs.
Both tests have to be run from a new opening of the patch (the normal situation for a patch.
David.

So you are saying that the seed only displaces the series? This is worrying indeed. Do you know how the displacement works, though? It doesn't seem to be linear, ie. "seed 2" doesn't seem to be "seed 1" + 1.

Maybe you could do something like this:

Of course it is still determined, but at least it will break the series that you have described above, if seeded properly with [time]. And if that's not enough then you can easily create n number of parallel randoms, or n depth layers...

One more thing: if you are set on using [noise~] for this, you should consider using [switch~] to turn DSP off in the subpatch after the output, in order to save CPU. Of course there's a chance that this too will affect the randomness though! Does [noise~] restart every time DSP is switched on? I haven't tested this, but it would be easy to do.

@lead said:

maybe process the lists from cartesian to polar coordinates (or visa versa) then *-1 +1?

Not sure what you mean exactly. Admittedly, my suggestion was rather cryptic as well.

Anyway, I was thinking about the situation of a test signal: how long is that signal? Probably too long to fit in one fft frame of reasonable length. In that case, I don't think you can invert it's phase spectrum in frequency domain. But no problem: just do a time reversal in signal domain, and it's phase spectrum will be inverted automatically. To be explicit here: I mean you must time-reverse the samples of the original test sweep (not the test result signals). Time reversal does not change the magnitude spectrum, only the phase spectrum.

So remains inverting the magnitude spectrum of the time-reversed test sweep. A log sweep does not have a flat magnitude spectrum, so you need to compute the multiplicative inverse of the magnitude coefficients (in frequency domain, using polar coordinates indeed here). Beware of possible zero-magnitude points in the original, they can not be inverted of course. After magnitude inversion, go back to cartesian coordinates and from them to time domain. Now you have your deconvolution kernel in time domain.

The deconvolution kernel is the test sweep with phase and magnitude spectrum inverted. It can be considered a (very long) FIR filter. With this kernel you can do fast convolution of the test results, to deconvolve these. For this, you can use Ben Saylor's [partconv~] object. It does 'partitioned convolution' in frequency domain, with zero padding to avoid circular convolution.

Good luck. Please let us know if you have succes. It is an interesting technique to create impulse responses of acoustic conditions. Expensive reverb simulators probably rely on similar techniques. What is actually your purpose for it?

Katja

I've been wanting to solve this problem and have been meaning to learn dynamic object creation so I combined both endeavors. Created two patches, [dynthrow~ name] and [dyncatch~ name] which mimic the API of [throw~] and [catch~] but allows one throw~ to send to several catch~es (not the other way around).

Ex:
[dynthrow~ test]
[dyncatch~ test] [dyncatch~ test]

This example will create two sets of throw~ and catch~. One will be assigned the name test.1 and the other test.2. A third dyncatch~ would create a test.3 and so on.

If you remove one of the dyncatch~es it will not remove it's corresponding catch~ (couldn't figure it out). It's a little annoying because PD will start sending errors to the console, but if you create another dyncatch~ it will assign it to that available throw~.

It doesn't matter whether your create the dynthrow~ before or after it's corresponding dyncatch~.

Requires PD-Extended and I have only tested this with version 0.40.3
Give it a whirl, let me know if it works out.

http://www.pdpatchrepo.info/hurleur/dyncatch~.zip

so liquid media seems to be windows only. so see attached.

i wrote an object called [openfile] that is windows only. has worked for me so far but use at you own risk.

the file launches a vbscript in the background that sends keystrokes to a window of your desire.

open the included text file (not minimize but open(can be in the background)
open pd and turn on the metro by hitting the toggle box. the textfile will pop to the front and starting printing "Test"
The script works by calling the window by name in title bar, then sending keystrokes

in case no one wants to open the script:

'''''''''''''''''''''''''''''''''SendKeyToApp.vbs
'May 8, 2008
'JonGrant
'Send text string to desired open window
''''''''''''''''''''''''''''''''

Option Explicit

'On Error Resume Next

Dim objWshShell

Set objWshShell = CreateObject("WScript.Shell")

objWshShell.AppActivate "Test"
objWshShell.SendKeys "Test"

'figure a way to do command line and the command is
'sendkeystoapp.vbs windowTitle string
'e.g. sendkeystoapp.vbs Test.txt Test
'This will send Test to a textfile call Test
'Just replace above with these
'Option Explicit
'On Error Resume Next
'Dim strAppWindowTitle
'Dim strSendString
'Dim objWshShell
'Set objWshShell = CreateObject("WScript.Shell")
'strAppWindowTitle = WScript.Arguments.Item(0)
'strSendString = WScript.Arguments.Item(1)
'WshShell.AppActivate appWindowTitle
'WshShell.SendKeys strSendString

http://www.pdpatchrepo.info/hurleur/sendKeys.zip