Hello, I am wondering if it is possible to use the rfft~ object to analyze an incoming sound, and output it's harmonics (sinusoidal peaks, including their amplitude) in order of frequency from low to high?

sigmund~ and fiddle~ are great at detecting them, but both seem to re-order the peaks in order of their amplitude not frequency (which unfortunately won't work for me ...sadly because they do EVERYTHING else I need!)

I'm trying to detect the first 7 harmonics of a sound that is run through my patch. Is it possible to route the frequency and amplitude of each harmonic to it's own outlet (like with fiddle~ or sigmund~) with the rfft~ object? Or, alternatively, is it possible to lock the order of the harmonics in fiddle~ or sigmund~ so that they always output in order of frequency from low to high?

Many thanks in advance, any help would be greatly appreciated!

@swell07 You will need to tick all 4 devices, even though they are the same device..... and set them to 2 channels each. That should work, but there is no guarantee that they will be in the "correct" order.
But yes, you then use [dac~ 1 2 3 4 5 6 7 8]..... Pd will add each pair to a "multiple device" automatically increasing the indexes.
Even using ASIO (using Asio4All http://tippach.business.t-online.de/asio4all/ for example) they can pop up in the wrong order, although usually the wrong order is sticky.... they always pop up in the same wrong order when you start Pd. It might change if you re-install the soundcard driver, or there might be a way to re-order in the Realtek setup panel in Control Panel (if there is one).

PS, I think you can leave your Windows setting as stereo if you wish...... Pd just asks for the list of audio pins from the os and lets you choose from what is available.
David.

Multi-Touch Canvas
Canvas, calibrated Multi Touch technology by Depth Sensor, generates a sound when the brush touches a canvas, and manipulated by painting.

PwS (Painting with Sound) is a Pure Data patch which corresponds with Depth Sensor (Xbox 360 Kinect) to implement Multi-Touch technology on a canvas, triggering a sound when a brush touches the canvas, and manipulating by painting.

download zip file (Pure Data Patch and Installation Guide):
www.paintingwithsound.net/instrument/pws/
www.github.com/yenatdollar/PwS

tutorial video:

more info @ EToOto (website) or GitHub

For the demo, I used 3 layers with 300 neurons in the hidden layer. More layers could be a solution, but ann_mlp locks up pd immediately if I try to create 5 or more layers. (and there is a warning in the help patches to not set the layers parameter too high when creating a network)

I had seen those other input/output tips, which were definitely helpful. But reading them again now, I hadn't considered the idea of deliberately scaling some of the vectors between -2/2, -3/3, etc. in order to give more weight to certain inputs. I might give that a try! Thanks.

Purr Data is finally released!
Purr Data inherits the goodness of Pd-l2ork and runs on Gnu/Linux, Windows, and OSX. Infinite undo, enhanced editing and 2d drawing, and most of the the externals from Pd-extended (plus more from Pd-l2ork).

[Edit]
2.2.4:

• fix [wrap~] inconsistency
• port mouse events from [hcs/cursor]
• fix bug with dollarsigns in struct names
• add some "legacy_mouse" classes to support externals that report mouse events: "legacy_mousemotion", "legacy_mouseclick" and "legacy_mousewheel"
• fix bug loading default libs on OSX

2.2.3:

• fixed overallocation bug that made loading soundfiles into arrays take up unnecessary amount of memory (4x-8x overallocation)
• fix some utf8 string handling routines
• port fixes for [soundfiler] from Pd Vanilla
• fix bug with "$@" that could cause invalid reads in some cases
• fix [initbang] functionality
• fix crasher in [pdinfo]

New in 2.2.2:

• fixed usability issues with the dropdown object

New in 2.2.1:

• fix stray GUI bugs
• fix some external libs that weren't building under Windows
• fix some OSX key event bugs

New in 2.2.0:

• fix GOP sizing algo to accommodate small GOP abstractions
• turn off anoying Gnome-keyring popup that appears on some systems
• bump nw.js GUI toolkit to 0.22.1
• fix arrow-key navigation-- use arrow keys for scrollbar navigation in runmode, turn off in editmode
• ignore iemgui label in bbox computation for "-legacy" mode
• fix OSCx library on arm builds
• guard against more out-of-order messages from Pd to GUI
• clean up and simplify build instructions
• leave enough space in GOP abstractions to accommodate all xlets
• fix search path bug
• update some of the documentation, removing old "messageoddness" patches that no longer apply to Purr Data
• update unauthorized library
• clean up and simplify the repository code/structure

New in 2.1.2:

• minor bugfix in the console (duplicate messages weren't printed after clearing)
• some minor fixes in the default startup configuration
• some cosmetic changes in the accompanying README and license information
• various bugfixes in objects and internal API functions (message boxes, dropdown atom, loadbang-related issues)
• updated lyonpotpourri to the latest 3.0 version to fix various 64 bit issues on Linux and macOS
• saving the preferences is much faster on the Mac now
• new animated "About Pd-L2ork" popup; also, the proper version is now shown in the generic "About" box on the Mac

New in 2.1.1:

• normalized range for [bendin] (keep old behavior under legacy flag)
• added "mouseenter" and "mouseleave" events for data structures
• fixed "Recent Files" under Windows
• cleaned up documentation in repo
• fix for [midiclkin] (#255)
• added "l2ork_version" message for [pdinfo]
• make loader search order the same as Pd Vanilla
• fixed cord inspector font size
• silence spurious error when autopatching a signal object
• added a [dropdown] object for choosing a value for an atom box (interface not stable yet)
• made gatom resizable by click-dragging in edit mode
• added "<ctrl-mousewheel>" for zooming
• added solarized and inverted solarized gui presets
• fixed mycanvas stroke color updates
• improvements to mode 4 of intelligent patching
• fixed "<Delete>" not deleting a selected object on some systems

New since rc5:

• fixed display bug with [vu] on graph-on-parent canvas
• fix documentation for timer-help.pd
• fix "open" method for [ggee/image]
• default to the user's home directory on OSX app bundle
• open the help browser file browser in the doc folder
• add a canvas "Print" menu item (under "File" menu)
• allow option to save the zoom level with the canvas
• fix a data structure crasher

please report lots of bugs to

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

Binaries:

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

I actually managed to make a plugin that colors every window in 8.4, not sure about previous versions. I just uncommented the create tcl_entry command at the bottom of the pdwindow tcl file (which enables the command prompt), used it to inspect all the windows and options, then kind of hacked away with a recursive proc. It worked for me on .46 - mac.

here it is ketea-theme-plugin.tcl You can see if that works?

It was even coloring the embedded_button_bar-plugin but @danomatika made a tk 8.6 version however; the way the frame was rendered became ugly so I thought I should refactor things into grid instead of pack. But thats different problem.

I'm pretty sure that my answer lies within syscalls in the c code, but I have zero knowledge of either the control flow on the c-side or syscalls in general.

Like look at this :
tcl:

#change the text in an existing text box
proc pdtk_text_set {tkcanvas tag text} {
    $tkcanvas itemconfig $tag -text $text
}

inside a giant c function called rtext_senditup

else if (action == SEND_UPDATE)
    {
        sys_vgui("pdtk_text_set .x%lx.c %s {%.*s}\n",
            canvas, x->x_tag, outchars_b, tempbuf);
        if (pixwide != x->x_drawnwidth || pixhigh != x->x_drawnheight)
            text_drawborder(x->x_text, x->x_glist, x->x_tag,
                pixwide, pixhigh, 0);
        if (x->x_active)
        {
            if (selend_b > selstart_b)
            {
                sys_vgui(".x%lx.c select from %s %d\n", canvas,
                    x->x_tag, u8_charnum(x->x_buf, selstart_b));
                sys_vgui(".x%lx.c select to %s %d\n", canvas,
                    x->x_tag, u8_charnum(x->x_buf, selend_b) - 1);
                sys_vgui(".x%lx.c focus \"\"\n", canvas);
            }
            else
            {
                sys_vgui(".x%lx.c select clear\n", canvas);
                sys_vgui(".x%lx.c icursor %s %d\n", canvas, x->x_tag,
                    u8_charnum(x->x_buf, selstart_b));
                sys_vgui(".x%lx.c focus %s\n", canvas, x->x_tag);
            }
        }
    }

...I might be able to hijack these arguments, but I'm not sure how yet.

Hi,

I'm creating abstracts of DPW oscillators according to Välimäki's paper from 2010.
http://mac.kaist.ac.kr/pubs/ValimakiNamSmithAbel-taslp2010.pdf

He proposes the DPW in different orders. (1st, 2nd ... 6th) to reduce the aliasing of digital oscillators. the 1st to 4th order models work absolutely fine but the 5th and 6th order version get heavily distorted if I go below frequencies of 200Hz (for the 5th-order version) and 600Hz (for the 6th order verision).

Here are my abstracts. The inlet expects frequency in Hz and the outlet is an audio signal.
DPW6th_saw~.pd
DPW5th_saw~.pd

Does anyone know why? Did I do something wrong in the patch?

best,

Matthias

GNU nano 2.2.6 File: /etc/network/interfaces

interfaces(5) file used by ifup(8) and ifdown(8)

Please note that this file is written to be used with dhcpcd

For static IP, consult /etc/dhcpcd.conf and 'man dhcpcd.conf'

Include files from /etc/network/interfaces.d:

source-directory /etc/network/interfaces.d

auto lo
iface lo inet loopback

iface eth0 inet manual

#allow-hotplug wlan0
#iface wlan0 inet manual
#wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

allow-hotplug wlan0
iface wlan0 inet static

address 10.1.1.101
netmask 255.255.255.0
network 10.1.1.0
broadcast 10.1.1.255
gateway 10.1.1.1
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

allow-hotplug wlan1
iface wlan1 inet manual
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

you are very close with your understanding of how pack works.

it will only output when a value is input to its left inlet. this is a basic pd standard, followed by most objects. (there are exceptions, such as [timer])

so, actually you can throw away most of those [f ] objects you created, and just leave 1 for the y-abs value, that can be triggered by doCalcAbs bang.
the other receives (ymax, ymin, xabs, etc) can be plugged directly into [pack f f f f f f ] where they will be stored until the left inlet gets a value.

actually, you can make it even simpler by just sending directly from the number boxes into the [pack f f f f f] object.

be careful though. there is one big 'mistake' in your patch. you have two bangs: getValues and doCalcSlope. It is not 'wrong' to send many patch cables from one bang (or any other object), but the order in which the messages are sent is only decided by which order the patch cables are created. If you do any sort of cut and paste or something like that, the order may change, and you will have know way of knowing what order the bang messages go. In general, it is a good idea NEVER to send more than one patch cable from one outlet of any object. Even if the order doesn't matter, it is still good practice and safer to use [t b b b b b b] or something like that to force the order. have a look at the help file for [trigger] ( [t ] ) and you will hopefully understand.

In your patch, the order DOES matter, because you need to send the value to the left inlet of [pack f f f f f f] LAST, so that it triggers properly.

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

Hey,
I want to build a little "patch-analyser" (in pd since I don't know about "deeper" programming in C and so on). Mainly because I dislike the [trigger]'s & I just want to avoid using them.
It never ever happend that the order of objects being computed suddenly changed without triggers, but triggers slow things down alot. <- Just measure the "[realtime]" of banging e.g. "[until]" 100000 with and without [trigger]'s...
So as far as I can see there "technically" is no need for those triggers.
The order is saved within the save-file!
They just help visualizing the processing-structure! Some people consider using triggers as rather clean which may be true for looking at the patch but not for processing it.

..in short: without trigger's I build patches from right to left (because right inlets are the passive ones most of the time) so that most right objects (the ones you placed first) are computed at first!

It's different with "audio"-data (the vectors). There an object's output only is computed after all inlets have received data... (this makes sense sice each element of one vector can "interact" with each element of another vector & they are connected to the sample-rate)

Anyways, not using triggers but trying to keep a clear visual structure may "uglify" the appearance of the patch sometimes, or just doesn't work (more than one active inlet and so on..)

...Sooo the easiest way to keep the information about the order visualized is "on demand".
Imagine this: You select an object (msg etc.) and its outgoing (and incomming) connections get numbers written next to them according to the order they are processed.
This can be programed in pd itself since pd is capable of creating object's via text (msg) & saves the processing-order with the save-file (hopefully even before)
Next step would be beeing able to change the processing-order just by changing those numbers (helps alot with multiple connections & even [trigger]'s are not comfortable in this situation..) ... but that's far future...
What do you think of this?!
-Or an switchable extra graphical-layer containing those numbers for all objects (at once)... I gonna upload a patch that demonstrates this soon...

Now here comes the important part (still reading?! ):
Does anyone know if and where data (e.g. a pre-savefile) is stored as long as it's not saved???!!! I ask because I managed to analyse the text of save-files somehow, just by reading out the file with some textread-objects in pd... but I don't know where to find data of unsaved patches. (and it's a little annoying to save your patch every time just to analyse the connection-order)
Aaand is there a method to identify a selected object?? (For now I use a unique message that is sent to the object I want to "select" and then trace that connection in the save-file)

Actually I found something like this (just have to look where that was..), but actually it didn't work since it was made for earlier versions and it had to change some pd-dll's (yep -Windows..).
As usual don't hesitate to correct me if I'm wrong.
And please respond even if you just like or dislike this idea...
Bye Flipp