Re: [PD] copy data between arrays

[Giulio Moro via Pd-list]

If you need 'instantaneous' (zero logical time) copy, then [array get] and 
[array set] are probably a good option, but even though this will not stop the 
DSP, it may well cause an audio dropout, typically in the case of large copies 
on a system with small blocksize and small buffer size and non-trivial CPU 
usage. These factors all interact in determining how much headroom (in terms of 
CPU time) there is for a copy to happen within a single audio callback without 
causing a buffer underrun.
If you need a real-time friendly[1] copy, consider using a pair of tabread~ / 
tabwrite~. In this case, if you need to copy faster than real time[2] (i.e.: 
copy one second worth of data in less than one second), you should be able to 
do that in an oversampled  subpatch(via [block~]).

[1]: real-time friendly in the sense of the very loose definition of an 
operation that completes in a finite amount of time and that has an (almost) 
constant CPU time for each audio callback.
[2]: real time as in real-world time in seconds given by arraySize/samplingRate

Benjamin Wesch wrote on 23/04/2024 10:38:

hi,

to avoid confusion here: the "clipboard" in this case is actually a file.
it certainly works to write and read arrays to/from disk like that (as
documented in "other-messages" subpatch of the [array define] help) -
but this is not a RAM copy/paste as it might seem. :)

cheers,
ben

Am Di., 23. Apr. 2024 um 10:29 Uhr schrieb Peter P. :


Thanks for this hint Oliver!

Can't test right now but am curious if audio drops out (eg. playing a
sine test tone while copying some 10secs of table data) and if there is
any (dis)advantages over the get/set method below.

cheersz, P

* oli...@klingt.org  [2024-04-23 10:22]:

Also just found out by chance that writing and reading to/from clipboard also 
works !

[write clipboard(
|
[array define a1]


[read clipboard(
|
[array define a2]

Can you confirm this ?

Best

Oliver





Am 23. April 2024 10:15:00 MESZ schrieb "Peter P." :

Replying to myself here, after this solution has been suggested to me
off-list:

[bang(
|
[array get one]
|
[array set two]

seems to work for larger tables without audio dropouts.

Much appreciated help, thanks!
P

* Peter P.  [2024-04-23 08:54]:

Hi list,

I am sure this has been asked many times, but I can't find a solution in
the mailing list archive. How can I copy data between arrays, in my case
arrays of 48 samples without using externals and without blocking
the DSP computation (causing dropouts)?
I know that I can write to disk and read from it again, but is there a
way that does not require disk access?

Thanks for all ideas!
Peter




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list



--

Gesendet von meinem Endgerät




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list





___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list





___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] A web frontend for Pd

[Giulio Moro via Pd-list]

Here's something the Chair and Bela teams have been working on for a few 
months: a proof-of-concept web interface to Pd.

 https://github.com/BelaPlatform/pure-data-web-GUI

This leverages the refactored communication protocol effort by Iohannes in order to obtain a 
"toolkit-agnostic Core<->GUI Communication" 
(https://github.com/pure-data/pure-data/discussions/1695), which resulted in 
https://github.com/pure-data/pure-data/pull/1765 . This is part of a broader project outlined 
in https://github.com/pure-data/pure-data/pull/1693 .

Now, this pure-data-web-GUI repo comprises three components:

- pd: is started with -guiport so that it doesn't start its own GUI
- the "shim": a very thin layer of websocket that forwards messages to/from Pd 
and the browser
- the "frontend": the actual HTML5 stuff, written using the svelte framework.

For now, you can try it out with docker following the instructions included in 
the repo. The easiest way is to run it with the Pd it comes with (which is run 
inside docker and thus doesn't have audio/MIDI I/O capabilities), but you can 
easily connect it to your own Pd server instance (assuming it comes from this 
branch https://github.com/giuliomoro/pure-data-1/). The docker containers are 
used to simplify the development effort, but ultimately this can be packaged up 
in a self-contained app (even for Android, if required), or you can have it run 
embedded (e.g.: on a Bela board) while displaying the GUI in a web browser 
(which is actually our primary goal).

It is by no mean complete or perfect, but I hope it shows that there is a 
tcl-tk-compatible, non-tcl-tk future possible for Pd. As it is, it even allows 
(well, with a lot of effort on the user side, but very little effort was put 
into it from the dev side) to patch on a touchscreen.

You may be wondering how this differs from the purr-data web GUI. Good question. This is 
a complete rewrite and it aims to use "stock" Pd as a backend server, by means 
of a communication protocol that has been refactored (by Iohannes) such that Pd no longer 
sends out raw tk messages, but rather tcl-compatible commands that are higher level and 
also easier to parse in other languages (the parser here is written in js). So right now 
you can run the same Pd binary (from this branch) deciding at runtime if using a tcl GUI 
or a web GUI. Nifty. The aim is eventually to upstream this communication protocol into 
vanilla, to make it easier to swap GUI frontends. Hopefully this can eventually help 
other forks with custom GUIs such as PlugData so that they don't have to maintain their 
own fork of Pd.

Best,
Giulio



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] phase locked loop

[Giulio Moro via Pd-list]

i noticed that the CPU toll on BELA is quite high with puredata and fexpr~


If you are not going full-polyphonic, you could try to disable unused [fexpr~] 
objects based on the envelope's amplitude, either via [switch~] or using 
[start( and [stop( messages to [fexpr~].


maybe (if i take this further) i have to try and implement this in C directly 
(or as a pd external) to make it more cpu friendly.


I concur this would be the best way to optimise CPU performance and it 
shouldn't be too hard. Let me know if you need help.

Best,
Giulio

Simon Iten wrote on 14/03/2023 03:25:

thanks again for this, these explanations make it much clearer.

yes i also thought that one pll per string might be the ticket.

i noticed that the CPU toll on BELA is quite high with puredata and fexpr~

maybe (if i take this further) i have to try and implement this in C directly 
(or as a pd external) to make it more cpu friendly.

a sync osc would be a great external i think.

it is actually only 5 strings on my bass, so more of a pentaphonic pickup :) my 
bad..
the term hexaphonic is used among guitarists/bassists to describe a 
split-string pickup interchangeably.


my bass is standard 5 string tuning:

B: 30.87 HZ
E: 41.2
A: 55
D: 73.4
G: 97.99

every string has a two octave range.

i did a version of my “gr300” ish guitar to sawtooth converter in puredata with 
building blocks and it works but your pll is less prone to octave jumping 
somehow even with the same input filtering applied…



On 13 Mar 2023, at 22:01, Charles Z Henry  wrote:

On Mon, Mar 13, 2023 at 8:32 AM Charles Z Henry  wrote:


On Mon, Mar 13, 2023 at 7:41 AM Simon Iten  wrote:



i do not currently grasp the math in the fexpr~ objects, but will try to get 
into it…


It's a simple kind of dynamical system.  It responds based on its
inputs but also its internal state when receiving inputs.  That's why
[fexpr~] works well for this.  You can add additional expressions and
reference them from each other.  There can be internal hidden state
variables, etc


Right now, I just left the outlets all hanging out of synch_osc~ for
debugging.  Connect up some plots (maybe longer block sizes would be
better) to see what's in the

I'd say it's actually the *simplest* kind of dynamical system for
phase locking (and a very artificial one).  It's just a discretized,
noise-less little phasor. e.g.

[fexpr~ modf($y1+1.0/44100)]
is just a phasor that counts from 0 up to 1 over 44100 samples

So, if I want, I'll change that to use [samplerate~] and pass in
1/samplerate as a float $f2
[fexpr~ modf($y1+$f2)]

Now, add frequency in $y2, and multiply
[fexpr~ modf($y1+$y2*$f2);
80]
It's a 80 Hz phasor.

Next, I extend the phase that's stored in $y1 so it accumulates over
time between impulses from $x1 in $y3
[fexpr~ modf($y1+$y2*$f2);
80;
if($x1==1, $y1, $y3+$y2*$f2])

So, now I have phase and freq as functions of time, and I'll add in
some updates to the terms and put them in $y4, $y5 so that the updates
get added in when receiving an impulse from $x1
[fexpr~ modf($y1+$y2*$f2+$y4*$x1);
80 + $y5*$x1;
if($x1==1, $y1, $y3+$y2*$f2]);
($y4) phase update function of $y3;
($y5) freq update function of $y3 ]

With some re-ordering of things and adding in parameters and scaling
coefficients with $f inlets, that's basically what's in synch_osc~
right now

The choice of the phase and frequency update functions is what causes
the synchronization.

For anyone who's interested in some light reading (LOL), I noticed
Izhikevich has put "Dynamical Systems in Neuroscience" (~500 pgs) in
pdf at https://www.izhikevich.org/publications/
Chapter 10 is on synchronization and it has a section on
phase-locking.  It took me over a year to read this, much of the math
eludes me also

I want to make a version that's good for your hexaphonic pickup, you
know that just works well as a sensor and has clean output.
synch_osc~.pd has problems with low frequencies and I know where that
comes from
I think it has to be 6 PLL's, each tuned to the range of each string.
Can you tell me what the range is on your instrument?

Best,
Chuck





___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list





___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] pd 0.53-0test1 released

[Giulio Moro via Pd-list]

I am sorry if this conversation has taken place before and I missed it, but is 
it expected that the default parameters (size etc) for most (all?) iemguis has 
changed with 0.53 compared to 0.52 (and possibly all previous versions)?
E.g.:
hsl
 width: 128->162
 height: 15->19
 label font size: 10->12
 y-offset: -8->-10
tgl:
 Size: 15->9
 label font size: 10->12
 X-offset: 17->0
 Y-offset: 7->-10

I am asking because it's quite a big change in look and this was meant to be a 
minor release ... and it's not mentioned in the changelog

Thanks,
Giulio


Alexandre Torres Porres wrote on 16/10/2022 22:49:

Em dom., 16 de out. de 2022 às 16:34, Miller Puckette via Pd-announce 
mailto:pd-annou...@lists.iem.at>> escreveu:

To Pd-announce:

Pd version 0.53-0test1 is available from http://msp.ucsd.edu/software.htm
or (source only) via github: https://github.com/pure-data/pure-data

This is a test version that mostly just fixes bugs in version 0.52, 
including
one serious problem reading soundfiles.


Great, I imagine the actual final version should come quite soon.

I'll have a look to see if I can add a couple more documentation updates, I 
just found a typo in the [nbx] help file. I can also suggest more details to 
the release notes in the manual. We can mention the new deken version, and I 
can say there is at least one new feature, which is the unification of vertical 
and horizontal sliders and radio buttons, which can now have their orientation 
changed via the 'orientation' message. Maybe we can add that (I'll send a 
commit as a suggestion soon).


cheers
Miller



___
Pd-announce mailing list
pd-annou...@lists.iem.at 
https://lists.puredata.info/listinfo/pd-announce

___
Pd-list@lists.iem.at  mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list





___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] mobmubplat and env~

[Giulio Moro via Pd-list]

Not that I have any experience with mobmuplat, but to validate whether it is 
the env~ object that stops working with the GUI, try to use its output to 
control audio output (e.g.: attached patch). This will tell you whether it's a 
GUI or env~ issue. If this works, maybe try throttling the messages you send to 
the numberbox?



Simon Iten wrote on 27/08/2022 11:25:

h ithere,

i am using mobmuplat for a live-sound-fx setup, which works quite nicely! (up 
until now i only used it as a midi controller setup)

i am trying to get a sort of input vu meter working, so i can adjust the gain 
in the analog domain before it hits the iPad.

i did a simple test patch, that works in the editor, but does not on the actual 
device. the slider does not move at all.
if i open the PD-patch directly in mobmuplat it works. (the numberbox displays 
the loudness correctly)
it is as if the env~ object stops working, as soon as i try to use the mobmu 
GUI..

maybe someone knows what is going on? or am i missing the obvious? find 
attached the two test files.


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

#N canvas 593 27 546 593 12;
#X obj 45 145 *~;
#X floatatom 96 79 5 0 100 0 - - - 0;
#X obj 96 117 dbtorms;
#X obj 5 42 cnv 1 535 1 empty empty empty 8 12 0 13 #00 #00
0;
#X obj 5 552 cnv 1 535 1 empty empty empty 8 12 0 13 #00 #00
0;
#X obj 45 169 env~ 2048 1024;
#X obj 45 114 adc~;
#X obj 136 54 loadbang;
#X msg 103 55 100;
#X floatatom 46 243 5 0 0 0 - - - 0;
#X obj 155 274 s toGUI;
#X msg 133 240 /input \$1;
#X connect 0 0 5 0;
#X connect 1 0 2 0;
#X connect 2 0 0 1;
#X connect 5 0 9 0;
#X connect 6 0 0 0;
#X connect 7 0 8 0;
#X connect 8 0 1 0;
#X connect 9 0 11 0;
#X connect 11 0 10 0;
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] JACK and blocksize

[Giulio Moro via Pd-list]

On Bela we've been running with blocksize of 8 for a few years since 2016 and 
then we moved to 16 samples per block around 2018 I think (in both cases 
redefining the problematic constants). I think only in a couple of occasions 
this caused an incompatibility with a couple of externals relying on a 
hardcoded value of 64 instead of taking DEFDACBLKSIZE value from `s_stuff.h`.
Another drawback is the CPU penalty of running smaller blocks (which is what 
made us switch from 8 to 16 samples per block at the time). Smaller blocksizes 
means in general higher CPU usage. When running with a larger buffer size 
(which may be desirable when CPU performance is more important than latency), 
if the blocksize is hardcoded, the CPU penalty remains.

A runtime value would be a beneficial change for us.


Christof Ressi wrote on 16/01/2022 18:04:

This sounds reasonable. I have made a feature request on GitHub: 
https://github.com/pure-data/pure-data/issues/1549

When I have time, I can make a PR. Or maybe someone else wants to do it?

Christof

On 16.01.2022 17:15, Athos Bacchiocchi wrote:

I tried setting DEFSENDVS, DEFDELVS to 16 as well, and everything seems to be 
working fine now.

> (I would not recommend doing this in practice, though.)

Why wouldn't you recommend it? (I am assuming you were referring to changing 
the DEFSENDVS/DEFDELVS define values).

I agree that it would be nice to have the "internal/rendering" blocksize of Pd 
be a runtime parameter as well.

If I understand correctly, one would have to:
- Add a runtime flag, eg. -rendering-blocksize (as opposed to the existing 
-blocksize)
- Modifying all the code depending on the DEFDACBLKSIZE to use the run-time 
value instead. I guess one way to do this would be providing the value through 
a global function so that the value cannot be changed from anywhere but the 
startup code.
- Have the default value of this now modifiable rendering block size still be 
64 for backward compatibility
- Making sure that the io block size is always forced to be at least the size 
of the rendering block size
- For alsa settings, add the additional values that can be set to the menu for 
the io block size

Would that be enough?

As for the need for it, I would personally use it, I tuned my linux system to 
run at 16 samples but I cannot use such settings when I want to run Pd (I can 
with Bitwig and Bespoke synth).
In general I think that nowadays it would be useful, considering linux and Pd 
can be run in all sorts of embedded devices that in turn are part of more 
complex signal chains (eg: guitar pedalboards) together with several other 
digital gadgets, with all the latencies adding up.

Also, if I understand correctly, this would improve the time granularity with 
control-rate objects and messages... even though on the other end it might 
increase the relative overhead of the control-rate processing compared to the 
audio-rate one.

Athos




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Multiple audio outputs on a single-board computer ?

[Giulio Moro via Pd-list]

disclaimer: I work for this company

We sell the CTAG-FACE (4in/8out) and CTAG-BEAST (8in/16out). These work with 
BeagleBone Black via ALSA or Bela's ultra-low-latency environment. No fiddly 
USB ports, relatively compact, super reliable, works out of the box.

https://shop.bela.io/collections/ctag-multi-channel-audio-system



Antoine Villeret wrote on 17/03/2021 08:34:

Hi,

Pd under works with any sound card supported by Linux.
One good and cheap option is the ESI Gigaport HD+ which provides 8 analog 
output for less than 200€.
I successfully test this card on Raspberry Pi few years ago.
Nowadays with RPi4 and its upgraded USB and ethernet chipset you could even 
think plugin 2 of them on the same board.

There might be also some other option.

Cheers

A

Le mer. 17 mars 2021 à 07:53, Pierre Massat mailto:pimas...@gmail.com>> a écrit :

Dear all,

I haven't posted anything on this list in years.
I'm trying to build a system to play several sound files in a loop,
each around 2 minutes in length, all at the same time. By "several" I
mean 10 to 15 different files. While I'd have no problem making a Pd
patch to achieve this, I have no idea what hardware I could use. I
have a limited budget, and I was planning on running Pd on a Raspberry
Pi (or similar single-board computer).

Is there any cheap way of outputing than many channels from a single
(a couple of) RPi ?

Thanks in advance,

Pierre.



___
Pd-list@lists.iem.at  mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list





___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] comport and/or MIDI on Tiny Core Linux

[Giulio Moro via Pd-list]

Each Makefile has a different way of looking for the path where m_pd.h, and 
where it is located on your system depends on how you installed Pd ...
normally `find /usr/include /usr/local/include -name m_pd.h` will tell you 
where the file is. Once you know where it is, you can inspect the `Makefile` to 
figure out which way to pass this information to it.
Normally this boils down to passing some options to `make`, such as 
PDINCLUDEDIR=/path/to/containing/folder or CFLAGS="-DPD 
-I/path/to/containing/folder" or others, depending on the content of the Makefile 
(these are two real-world examples). (or you can just hardcode the path in the Makefile 
next to where you see a `-I/somepath `, add ` -I/path/to/containing/folder` and see if it 
works.

A link to the source files would be useful if you need further help.


Yann Seznec wrote on 27/10/2020 19:34:

OK interesting - with the verbose flag on I can see that it is finding 
comport.pd_linux, but it says “/lib/libc.so.6: version ‘GLIBC_2.27’ not found 
(required by /home/tc/comport_test/comport.pd_linux)”

I assume that means that it needs to be compiled for the board specifically, as 
you mention.

Unfortunately when I try to compile it on the board I get yet another, 
different error. In that case it says “fatal error: m_pd.h: No such file or 
directory”.

I think I understand that it’s looking for where Pd is installed, but I can’t 
seem to find where that file is in Tiny Core Linux.

Thanks Giuilio!


On Oct 27, 2020, at 3:14 PM, Giulio Moro  wrote:

That's a Linux build, but is it an ARM build compatible with the architecture 
in use?
Try `file /path/to/comport.ld_linux` and make sure you get the same result as 
you'd get for any externals that actually work. You can run `Pd` with the 
verbose flag and that should print some extra info about the paths it is 
attempting to open. In fairness, it should be pretty straightforward to just 
build it from source on the board, which guarantees you get the correct binary.


Yann Seznec wrote on 27/10/2020 19:01:

Hello everyone,
As a follow up to my post a few weeks ago about startup times on Raspberry Pi, 
I have been exploring Tiny Core Linux (v9) on a Pi 3. Generally speaking this 
is super promising, with startup times around 15 seconds and it seems very 
stable.
Some of the things I want to run on this system require external libraries. I 
have managed to get zexy working, for example, by simply including the library 
in the same folder as the patch that uses it.
I have not had the same success with comport. Including a linux build of the 
comport object in the folder with the project does not work - I get a “couldn’t 
create” error when I launch the patch. I have tried declaring the library with 
the -lib flag, but that gives me an error saying “comport: can’t load library”.
I have installed the USB-Serial extension, though I’m not sure if I’ve missed a 
step there to make it work properly.
This feels like a long shot, but has anyone managed to get comport working on 
Tiny Core Linux?
Alternatively, has anyone used USB MIDI with Tiny Core Linux? That isn’t 
working for me either.
As usual, any tips would be excellent, many thanks.
Yann
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list






___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] comport and/or MIDI on Tiny Core Linux

[Giulio Moro via Pd-list]

That's a Linux build, but is it an ARM build compatible with the architecture 
in use?
Try `file /path/to/comport.ld_linux` and make sure you get the same result as 
you'd get for any externals that actually work. You can run `Pd` with the 
verbose flag and that should print some extra info about the paths it is 
attempting to open. In fairness, it should be pretty straightforward to just 
build it from source on the board, which guarantees you get the correct binary.


Yann Seznec wrote on 27/10/2020 19:01:

Hello everyone,
As a follow up to my post a few weeks ago about startup times on Raspberry Pi, 
I have been exploring Tiny Core Linux (v9) on a Pi 3. Generally speaking this 
is super promising, with startup times around 15 seconds and it seems very 
stable.

Some of the things I want to run on this system require external libraries. I 
have managed to get zexy working, for example, by simply including the library 
in the same folder as the patch that uses it.

I have not had the same success with comport. Including a linux build of the 
comport object in the folder with the project does not work - I get a “couldn’t 
create” error when I launch the patch. I have tried declaring the library with 
the -lib flag, but that gives me an error saying “comport: can’t load library”.

I have installed the USB-Serial extension, though I’m not sure if I’ve missed a 
step there to make it work properly.

This feels like a long shot, but has anyone managed to get comport working on 
Tiny Core Linux?

Alternatively, has anyone used USB MIDI with Tiny Core Linux? That isn’t 
working for me either.

As usual, any tips would be excellent, many thanks.

Yann


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list





___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] ISO works combining PD and sculpture

[Giulio Moro via Pd-list]

There are a number of Pd-based sculptures done with Bela, see for instance:

Fedde Ten Berge 
https://blog.bela.io/2017/12/12/fedde-ten-berge-instruments-bela/
Yann Seznec https://blog.bela.io/2020/06/24/trampoline-synth/
John Ferguson, Erik Griswold, Paul Bardini, and Daniel Della-Bosca 
https://blog.bela.io/2020/06/16/scatterfields-rotating-sculpture/
Manuel Vázquez https://blog.bela.io/2019/11/27/manuel-vazquez-laser-control/
A lot of people and guitars at University of Oslo 
https://blog.bela.io/2018/03/02/sverm-resonans-bela-interactive-guitar-installation/
Giacomo Lepri and Alessia Milo 
https://blog.bela.io/2019/06/26/chowndolo-milo-lepri/
Helen Leigh 
https://blog.bela.io/2019/09/19/trill-helen-leigh-craft-circuit-sculpture/
Yann Seznec 
https://blog.bela.io/2020/03/06/book-impractical-musical-devices-yann-seznec/


Jaime Oliver wrote on 27/10/2020 16:24:

I did this one a couple of years ago:
http://www.jaimeoliver.pe/caracoles-iv-2018

On Mon, Oct 26, 2020 at 5:16 PM hans w. koch mailto:hansw.k...@gmail.com>> wrote:

i did quite a few (and counting):
mengenlehre: https://www.youtube.com/watch?v=M7CfOGga8gU
clock of fifths (app version,made with mobmuplat): 
https://www.youtube.com/watch?v=l0V57rxAJoA
clock of fifths (installation): https://www.youtube.com/watch?v=I6ef9XVDf9U
shanti: https://www.youtube.com/watch?v=jxhYZCgtVgg

hth, best

hans

 > Am 26.10.2020 um 20:54 schrieb bbob mailto:fluxm...@gmail.com>>:
 >
 > for my students, I'm looking for examples of work that combines PD and 
sculpture (or installations)... i've got a few of the obvious 
pd-sequencer-triggering-drum-solenoids to show them, what else?  links to artist sites 
&/or videos appreciated.
 > ___
 > Pd-list@lists.iem.at  mailing list
 > UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list




___
Pd-list@lists.iem.at  mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list



--
**
Jaime E Oliver LR
www.jaimeoliver.pe 


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list





___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Startup times to run Pd patch on Raspberry Pi

[Giulio Moro via Pd-list]

Never used one, but you can try tweaking the "After" or "Requires" parameter in 
the systemd script. On Bela, this commit cut down the power-to-sound time from 18 to 10 seconds 
(and there's room for improvement):
https://github.com/BelaPlatform/bela-image-builder/commit/a85b82b526f3529523b9b67a706ff2cda47539c4#diff-606dc24f4e7da91386681db20c65038b

(note that the comments in modules.conf that I added in that commit shouldn't 
be there, because they actually make the whole line invalid!)


wolfgang spahn wrote:

Hi Yann,

to make the boot-up time shorter one can run the Raspberry Pi without Desktop 
and start PD without GUI from terminal, that saves a lot of CPU power, too.

Best!
Wolfgang


Am 05.10.20 um 16:08 schrieb Yann Seznec:

Hi everyone, long time reader first time writer.

I’m wondering what people’s experiences are with regards to the startup time 
for running a patch on a raspberry pi.

For various reasons I’ve started to use Patchbox OS to auto-run my patches on 
startup, which is very reliable and consistent however it usually takes about 
60 seconds from switching on to making sound. This is on various models of 
Raspberry Pi 3.

Has anyone managed to speed this up? I haven’t tried the Raspi 4, perhaps that 
is significantly faster?

Thanks,
Yann


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list







___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] rendering pd patches outside pd

[Giulio Moro via Pd-list]

FWIW, there is something similar already (and yes it has the same limitations 
on in/out ports) https://github.com/sebpiq/pd-fileutils/ we are using it on 
Bela to preview Pd patches, so we made a couple of changes to fix some issues 
with it ( 
https://github.com/BelaPlatform/Bela/commits/master/IDE/public/js/pd-fileutils.js
 )
Hope this helps.
Best,
Giulio

Andre Osku Schmidt wrote:

hello "pudists?",

i'm tinkering on a pd-patch-to-svg thing* for web-browsers and ran to couple 
show-stoppers with pd patches (when used outside pd).

1. a pd-patch has no info how many in/out ports an element has.

i guess a "better" workaround could be a "cheat-list", but that would not work with 
"dynamic" inlets/outlets, right?
what do you think about adding inlet+outlet port counts in the pd patch file?

2. a pd-patch position/sizes are "hard-coded" to font size.

i guess its inevitable to not, right?
what do you think about adding an official font (and size?) for pd?
(that could then be included in pd and elsewhere)

or other solutions?
or is this not "worth" the "trouble"?
(its just for fun, and i got plenty of other fun ideas;)

cheerio
.oskude

* https://github.com/oskude/pd-svg

ps. been a whiiile since i last used pd, so excuse me if i forgot/missed 
something related/important.



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list





___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Sample loop - start and end point (WAV files)

[Giulio Moro via Pd-list]

libsndfile also can extract loop points from a variety of formats. The relevant 
code for wav is here 
https://github.com/erikd/libsndfile/blob/master/src/wav.c#L1140-L1163

Kjetil Matheussen wrote:

On Wed, Feb 12, 2020 at 10:56 AM Kjetil Matheussen
 wrote:


On Wed, Feb 12, 2020 at 10:14 AM Ingo  wrote:


Thanks, Dan!



They must be embedded in the "Marker Chunk" in AIFF and in the "Cue Point 
Chunk" in the WAV format.

This gives me a further idea for searching on.




Yes, loops are usually defined as "Loop Start" and "Loop End" cues,


Hmm, or maybe they are usually defined in the "smpl" chunk, I don't remember...

But here's the code to get loop data from a wav file in radium:
https://github.com/kmatheussen/radium/blob/master/audio/Sampler_plugin_wav_parse.c#L253

First it checks if there is a loop in the "smpl" chunk. If there isn't
loop data there, it checks for "Loop Start" and "Loop End" cues.



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list





___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Raspberry Pi: Loading Samples RAM problem

[Giulio Moro via Pd-list]

You cannot really "extend" the RAM of a board. You need a more clever way of 
loading samples. One common approach is to load only the beginning of all the samples in 
a table, and then whenever the sample is triggered, start by playing back the pre-loaded 
table, while you start reading the remaining of the file from disk with [readsf~]. Here 
is the code for such a solution: https://github.com/giuliomoro/dynamic-load-files-Pd

Jakob Laue wrote:

Dear list,
i have a little problem with my raspberry pi..
I have built an eight-track sample player patch that runs on a raspberry pi.
When the patch loads, it initially loads all the samples it finds in 
/home/pi/SamplePacks/SamplePack1, SamplePack2 etc..
into RAM using the standard approach:
- create two tables for each sample
- read data into tables with [read -resize table1 table2(
Afterwards I use [soundfiler] and calculate the frequency for [phasor] and so 
on and so forth.
The patch works when I load a total amount of 500 gb into RAM.
Today I tested to load 9 GB of samples and the result (obviously) is the pi 
crashing.
I have tested on a raspberry pi 2 and a raspberry pi 3. Both pis only have 1 GB 
of RAM so it's obvious that problems arise trying to load 9 GB of samples.
Do you have any hints or ideas how I could solve this problem? Loading from 
disk while performing is not an option (I think) because of audio pops.
Do you know any ways to extend the RAM of the pi?
Maybe you know of some other small boards like beagle or so that have more RAM 
than a pi.
Thank you very much! Jakob


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list





___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] mrpeach external for armv7

[Giulio Moro via Pd-list]

build it from source? as far as I remember, it is very straightforward.


On Monday, 24 June 2019, 15:28:26 BST, Csaba Láng  wrote: 


Dear list,
is there a way to install the mrpeach pack for armv7 with ubuntu 16.04?
Thanks,
Popesz

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] MIDI device showing up as an audio device in a singleboard linux device

[Giulio Moro via Pd-list]

I don't know why it shows up in audio, really.

/dev/midi1 is OSS (or an emulation of it). OSS is an audio/midi driver older 
than ALSA. I don't know anything about OSS, but maybe it lists the MIDI devices 
under audio as well?
Maybe this version of Pd has been built without support for ALSA? I think if 
you run ./pd -help, this should give you the available options. If it lists 
-ossmidi/-oss but does not list -alsa/-alsaadd/-alsamidi , then you know you 
don't have ALSA support.

Giulio


On Tuesday, 5 February 2019, 03:09:59 GMT, Alexandre Torres Porres 
 wrote: 


Em ter, 5 de fev de 2019 às 00:47, Giulio Moro  escreveu:
> So, assuming you have one MIDI device plugged in and also some sort of audio 
> codec, then it seems that ALSA  is recognizing these devices correctly. What 
> audio backend is selected in Pd? What (if any) MIDI devices show up?

The "sun4icodec [sun4i-codec]" shows up as an audio device, and it works for 
the onboard stereo output. 

The "USB Uno MIDI Interface" also shows up in the audio devices, but it doesn't 
show up in Preferences => MIDI, all i has is "/dev/midi1" - and then I decided 
to select it and... wow... MIDI input works...

this shows how little I know about linux, sorry, I really thought it was 
strange that a MIDI device shows up in Audio but not in MIDI... seems like all 
this is just how it's supposed to be, huh? If so, it still looks weird to me I 
have to say.



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] MIDI device showing up as an audio device in a singleboard linux device

[Giulio Moro via Pd-list]

So, assuming you have one MIDI device plugged in and also some sort of audio 
codec, then it seems that ALSA  is recognizing these devices correctly. What 
audio backend is selected in Pd? What (if any) MIDI devices show up?



On Tuesday, 5 February 2019, 02:42:17 GMT, Alexandre Torres Porres 
 wrote: 


here you go:

chip@chip:~$ amidi -l
Dir Device    Name
IO  hw:1,0,0  USB Uno MIDI Interface MIDI 1
chip@chip:~$ aplay -l
 List of PLAYBACK Hardware Devices 
card 0: sun4icodec [sun4i-codec], device 0: CDC PCM Codec-0 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
chip@chip:~$


2019-02-05 2:29 GMT, Giulio Moro :
> can you run
>  amidi -l
>  aplay -l
> in the terminal and post the results?
>
>
> On Tuesday, 5 February 2019, 02:26:18 GMT, Alexandre Torres Porres
>  wrote:
>
> Hi, so, I'm still trying to use this old and now just garbage C.H.I.P.
> computer (the 1st under 10$ single board computer). It's running Pd 0.49-0
> on a debian system.
>
> I'm plugging in MIDI devices like a nanokontrol and a MIDI-USB. They do show
> up, but not as MIDI devices, I can only see and select them in the audio
> properties.
>
> How crazy is that? Anybody ever seen this?
>
> Mighty Linux people, any hints on how to deal with this?
>
> Thanks!
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] MIDI device showing up as an audio device in a singleboard linux device

[Giulio Moro via Pd-list]

can you run 
  amidi -l
  aplay -l
in the terminal and post the results?


On Tuesday, 5 February 2019, 02:26:18 GMT, Alexandre Torres Porres 
 wrote: 

Hi, so, I'm still trying to use this old and now just garbage C.H.I.P. computer 
(the 1st under 10$ single board computer). It's running Pd 0.49-0 on a debian 
system.

I'm plugging in MIDI devices like a nanokontrol and a MIDI-USB. They do show 
up, but not as MIDI devices, I can only see and select them in the audio 
properties. 

How crazy is that? Anybody ever seen this?

Mighty Linux people, any hints on how to deal with this?

Thanks!
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] vanilla partitioned convolution abstraction

[Giulio Moro via Pd-list]

interesting thanks.
I am on Pd 0.49.1 on Mac (10.11.6) and when I open the conv~-help.pd file I 
often (but not always!) get the following error in the Pd console:
```
while executing

  ("uplevel" body line 1354)
  invoked from within
"uplevel#0 $docmds"
```
and sometimes some more, possibly having Pd crash.
Anyone else?

On Thursday, 3 January 2019, 04:19:50 GMT, Alexandre Torres Porres 
 wrote: 





Hi, happy new year.
Here's a vanilla partitioned convolution abstraction  
https://www.dropbox.com/s/pbkg8xy2yhy9bpo/conv~-vanilla.zip…

It is based on this http://tre.ucsd.edu/wordpress/?p=772


what you think, is it working? Both objects on the help file take about 40% of 
my CPU power, but I'm on a wild machine



I made some changes on the original work by Tom Erbe. It is supposed to be more 
efficient because the FFT on the input is only done once! I tried the idea of 
having each partition work with FFT saved on tables, so we wouldn't need to 
perform FFTs in different instances of clone, but that doesn't seem to be 
possible. And, well, it is made as an abstraction and all you need to do is 
give it the window size and the IR sound file name...

cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] save patch as an image

[Giulio Moro via Pd-list]

Possibly not what you are looking for, but on Bela we use a modified version of 
https://github.com/sebpiq/pd-fileutils to generate a preview SVG from a .pd 
file. This has the big advantage of not needing Pd, so you could run it in the 
user's browser or on a server, and consequently it has at least a couple of 
drawbacks:
- array/tables are not displayed
- the number of I/O of each object is determined by the number of I/O 
connections and not by the property of the object itself
There is at least one bug:
- comment lines don't wrap
Our version has a couple of fixes with respect to mainline, here it is: 
https://github.com/BelaPlatform/Bela/blob/master/IDE/public/js/pd-fileutils.js


On Sunday, 23 December 2018, 16:28:39 GMT, IOhannes m zmölnig  
wrote: 


On 12/23/18 5:25 PM, Alexandre Torres Porres wrote:

> Hi, what's your best way to do this?


install my patch2svg plugin, and use that.

gmar
IOhannes

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

signature.asc
Description: PGP signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Status of PD double precision

[Giulio Moro via Pd-list]

It's been done this past summer for Purr-data/Pd-l2ork. Here is the report: 
http://disis.music.vt.edu/pipermail/l2ork-dev/2018-August/002019.html

Best,
Giulio

On Sunday, 16 December 2018, 11:29:25 GMT, Dario Sanfilippo 
 wrote: 

Hello, list.

I'm just curious to know if anybody is actively working on a double precision 
version of PD. Please let me know if I can help in any way.

Best,
Dario
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Puredata and DMX using OLA

[Giulio Moro via Pd-list]

libola itself may have a number of deps: on my Debian system I get

$ pkg-config --libs libola
-L/usr/local/lib -lola -lolacommon -lprotobuf

so maybe IOhannes's second line could be amended to:

$ make -f /usr/share/pd-flext/dev/Makefile.flext ldlibs="$(pkg-config --libs 
pd-flext) $(pkg-config --libs libola)" SRCDIR=.

?

On Friday, 22 June 2018, 10:02:19 BST, IOhannes m zmölnig  
wrote: 

On 06/22/2018 10:33 AM, IOhannes m zmölnig wrote:
>> I tried to follow all the steps (installing Ola, compiling Flext), but the
>> object Ola2pd is not recognized by Pd.

btw, if you are on a recent Debian based distribution, building might be
as simple as:

~~~
$ sudo apt install pd-flext-dev libola-dev
$ make -f /usr/share/pd-flext/dev/Makefile.flext ldlibs="$(pkg-config
--libs pd-flext) -lola" SRCDIR=.
~~~

(that's two lines).

gfmads

IOhannes
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Pure Data and Bela - newb

[Giulio Moro via Pd-list]

there was an error in my debouncing patch, now fixed at the URL below. Sending 
a float into [delay] changes the delay time, and that gets me every time (I 
instinctively think that it just gets casted to a bang!).

Giulio


On Wednesday, 13 June 2018, 21:58:34 BST, Wendy Van Wynsberghe 
 wrote: 

Hi,

Ten years ago I learnt the beginnings of Pure Data - and now I have 
thrown myself into the deep end --> I'm trying to do a fairly simple 
Pure Data project on Bela (https://bela.io/) - and failing gloriously.

I have a Pure Data Patch that works on my computer, with keys from the 
keyboard.
Here: 
https://cloud.constantvzw.org/s/EcsZzoNte8k54xQ/download?path=%2F=microphone_record_save_play_key_one_file.pd
 


Current simple wish on Bela:
- pushbutton0 on digitalIn3 records sound from the microphone plugged 
into the line in
- pushbutton2 on digitalIn4 stops recording
- pushbutton3 on digitalIn5 plays sound


When I connect physical buttons and translate to Bela, my buttons bounce.
The Bela developer active on the forum proposed a debounce patch
https://github.com/BelaPlatform/Bela/blob/dev-modular/examples/13-Salt/DuoWave/debounce.pd
- which I'm trying to push into my patch, but without succes.

On the Bela forum I explain what I have been doing
https://forum.bela.io/d/570-pure-data-digital-ins-from-arduino-logic-to-bela/5

---> I'm pretty sure the problem lies with my beginner pd-qualities, 
that's why I have turned to this mailinglist

---> here's my last patch, with abstraction and with bouncy buttons
https://cloud.constantvzw.org/s/EcsZzoNte8k54xQ/download?path=%2F=microphone_record_save_play_key_one_file_bela_with_debounce_bis_bis.pd

Would someone/the list be willing to follow this through - that would be 
a great help!

Greetings,
Dywen


-- 
* 00 32 (0)476 / 89 06 58 *
* http://wvw.collectifs.net *


          *
    *
  *
  *
    *
      *
        *
          *
              *
                  C O N S T A N T
                        V Z W



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] suggestion: $0 in messages

[Giulio Moro via Pd-list]

Yeah sorry I have no idea how deep these nest, I am not familiar with that part 
of the code.
In this case the memory could be allocated in the stack and then passed to 
something like   pd_pushsymnoalloc(t_pd *x, t_gstack* y) 
which should in turn skip the allocation. But yes, a cached value seems to make 
much more sense.

On the topic of pre-allocated memory pools, SuperCollider, for one, uses a 
pre-allocated pool 
https://github.com/supercollider/supercollider/blob/master/common/SC_AllocPool.cpp
 but it throws an exception upon failure instead of allocating more memory.

Best,
Giulio

On Friday, 6 April 2018, 13:42:26 BST, Jonathan Wilkes via Pd-list 
<pd-list@lists.iem.at> wrote: 
On Friday, April 6, 2018, 6:24:13 AM EDT, Giulio Moro via Pd-list 
<pd-list@lists.iem.at> wrote: 

> I don't think it makes sense to have a malloc() and free() for each call to a 
> msg box.
> Pd is already not very real-time friendly, why make it worse?
> There could be ...
> - statically allocated memory for t_gstack y in pd_pushsym

But you can nest arbitrarily deep in patch loading, no?

Also, patch loading time typically doesn't need to happen in realtime, as 
you're also allocating memory for objects during that time plus probably 
taking an i/o hit when loading abstractions.

On the other hand, it would be interesting to use a memory pool like you 
mention below and see its effect on load time. At least for the "canvas" field 
of data structures in Purr Data I cache the binbuf so there's no i/o hit 
there, only memory allocations.


> - a pre-allocated memory pool meant for short-lived memory allocations to be 
> used in real-time critical cases like this. If no memory available from the 
> pool, only then allocate it (or allocate a new pool). There are probably 
> other cases around the codebase where this would make sense, but why not 
> starting with this?

I'd measure performance here first to determine the best course of action.
Even with a memory pool pd_pushsym is doing quite a few assignments. Pushing 
and popping on every msg box method may get be noticeably different than 
dereferencing a single cached value.

Measuring [trigger] performance I could see differences depending on how 
exactly the loop for the outlets was constructed.

-Jonathan


> Giulio

On Thursday, 5 April 2018, 22:54:44 BST, Jonathan Wilkes via Pd-list 
<pd-list@lists.iem.at> wrote: 

> On Thursday, April 5, 2018, 3:20:03 PM EDT, Dan Wilcox <danomat...@gmail.com> 
> wrote: 

> test? https://github.com/pure-data/pure-data/pull/346

That will add a malloc/free for every method call to a msg box. So 
I'd measure the performance impact before using that 
implementation.

On the l2ork dev list I mentioned a potential way to cache the glist 
in the t_messresponder to avoid allocation at message evaluation time. 
But we haven't implemented that yet (nor measured the current 
performance hit).

-Jonathan






Dan Wilcox
@danomatika
danomatika.com
robotcowboy.com




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] suggestion: $0 in messages

[Giulio Moro via Pd-list]

I don't think it makes sense to have a malloc() and free() for each call to a 
msg box.
Pd is already not very real-time friendly, why make it worse?
There could be ...
- statically allocated memory for t_gstack y in pd_pushsym
- a pre-allocated memory pool meant for short-lived memory allocations to be 
used in real-time critical cases like this. If no memory available from the 
pool, only then allocate it (or allocate a new pool).
There are probably other cases around the codebase where this would make sense, 
but why not starting with this?

Giulio

On Thursday, 5 April 2018, 22:54:44 BST, Jonathan Wilkes via Pd-list 
 wrote: 

> On Thursday, April 5, 2018, 3:20:03 PM EDT, Dan Wilcox  
> wrote: 

> test? https://github.com/pure-data/pure-data/pull/346

That will add a malloc/free for every method call to a msg box. So 
I'd measure the performance impact before using that 
implementation.

On the l2ork dev list I mentioned a potential way to cache the glist 
in the t_messresponder to avoid allocation at message evaluation time. 
But we haven't implemented that yet (nor measured the current 
performance hit).

-Jonathan






Dan Wilcox
@danomatika
danomatika.com
robotcowboy.com




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] mrpeach for raspberrypi ?

[Giulio Moro via Pd-list]

No idea, but your friend should be able to build them from source easily. I 
built them for the BeagleBone Black and that was straightforward.
On Tuesday, 8 August 2017, 19:14:53 BST, oliver  wrote:

hi,

does anybody know if the mrpeach externals (are compiled for the 
raspberry pi architecture ?

not me but a friend of mine (so i can't ATM be more specific) tried to 
install them via DEKEN as well as apt-get without success.


thanks for any hints !

best

oliver

-- 

/// http://pendler.klingt.org //
\\\ http://oliver.klingt.org  \\


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] failing to run some externals in libpd for android

[Giulio Moro via Pd-list]

As to "compiling but not working", I had issues in the past where some alloca() 
in [fiddle~] were failing on the BeagleBone Black (that is, Linux, but 
embedded), so it was failing at runtime with no meaningful error other than 
"segmentation fault". 

On Tuesday, 4 July 2017, 15:03:28 BST, Alexandre Torres Porres 
 wrote:

Awesome, thanks! My coding skills and experience is so poor that this makes 
sense :) 

But just so we're 100% clear, even if it compiles and works for mac, linux and 
windows, we can still have problems for android like compiling but not working?
cheers
2017-07-04 5:16 GMT-03:00 IOhannes m zmoelnig :

On 2017-07-04 03:49, Alexandre Torres Porres wrote:
> howdy, I've been testing libpd for android and some externals. I've managed
> to use pd's extra objects as well as a few objects from cyclone and also
> from another library of my own - but some externals will fail, they compile
> and create and everything, I just do not hear any sound! And they're pretty
> simple so I can't see any reason why they fail, here's one I couldn't run,
> for instance: https://github.com/porres/pd- else/blob/master/classes/ gbman~.c

i don't see any obvious problem, but some generic remarks:

- use `t_sample` for all signals.
don't use different types for input and output signals.
use types consistently and try to not convert between them too often
(even if t_float and t_sample are practically the same on *your* system
right now).

- data sent to perform routine:
you are passing in x, some signal-vectors and the vector length.
you are storing the samplerate as a member of x. why don't you pass it
directly? or rather: why do you pass in sp[0]->s_n directly, but
sp[0]->s_sr via "x".
you are also passing in a member of x (x_val), why don't you just
dereference `x` in the perform routine to get that value? apart from
that, what is this value there for in the first place? you seem to do an
awful lot of referencing/passing around/dereferencing just to never
actually use that value.


- you are mixing variable declarations and code (L118). this is valid
C99 code, but not ANSI compatible.
since/if it doesn't really improve the readability of your code, i'd
stick to ANSI and declare my variables only at the beginning of a code
block.

> What should I know or be careful about building external objects for
> android? How can I get more information about my problem?

often such problems come from uninitialized variables.

i don't know anything about libpd, but sys_getsr() in the constructor
looks fishy. it might well poison the hz (x_freq; hmm, is that used
anywhere?) and x_phase values.

run your program through debuggers:
- valgrind is very easy to use, and it often detects use of
uninitialized variables.
learn to use it: https://www.google.at/search? q=valgrind+tutorial

- if this doesn't give you plenty of hints
gdb is a very powerful debugger, you should probably learn to use it:
https://www.google.at/search? q=gdb+tutorial

- there's also the printf debugger, which might be easier to use in some
specific contexts:
https://stackoverflow.com/ questions/189562


__ _
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/ 
listinfo/pd-list



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] using bob~ with libpd for android

[Giulio Moro via Pd-list]

What EXTRA=true does when building with the Makefile is that it adds in the .o 
files generated by the .c files in Pure-data/extras to the prerequisites for 
the library and links them in. In practice, if you can add the .c files in 
extras/ so that they get compiled and linked in by your project you will be 
fine.I believe if you move them all in the src/ folder, this will probably work 
just fine. The files in extra/ are no different in principle from the ones in 
src/, they are only stored separately for historical reasons afaik.
Giulio

> On 23 Jun 2017, at 04:35, Alexandre Torres Porres  wrote:
> 
> I just use Android Studio, it has its own environment and scheme, so I 
> followed the tutorial by rafael fernandez. This issue is more about using 
> libpd inside android studio then building libpd for android. Not sure if this 
> makes sense or is in fact true, but it's how I see it.
> 
> Seems I have to do something in the code on my project that I don't know and 
> all I find on the internet seems to be outdated
> 
> cheers
> 
> 2017-06-22 23:17 GMT-03:00 Giulio Moro :
>> I have no idea how you build libpd for Android (I also assume that you are 
>> building it yourself).
>> 
>> When I build it for Linux I do something like:
>> 
>> `make EXTRA=true <>`
>> 
>> that flag `EXTRA=true` makes sure that the extras are compiled and linked 
>> into the `libpd.so` file.
>> I hope the above can be somehow translated into the system you are using to 
>> build libpd for Android.
>> 
>> Best,
>> Giulio
>> 
>> From: Alexandre Torres Porres 
>> To: Giulio Moro  
>> Cc: "pd-list@lists.iem.at" 
>> Sent: Friday, 23 June 2017, 3:10
>> Subject: Re: [PD] using bob~ with libpd for android
>> 
>> > I think you need to make libpd with EXTRA=true or something
>> 
>> sorry, I'm really a dummy in this field, I need more detailed steps, 
>> information
>> 
>> thanks
>> 
>> 2017-06-22 21:54 GMT-03:00 Giulio Moro :
>> I think you need to make libpd with EXTRA=true or something like that in 
>> order to include the extras in the libpd library file without need for extra 
>> files.
>> Or at least that's how it works on linux/mac, no idea about android.
>> 
>> Just double check in the build log that bob~.o actually gets compiled and 
>> linked in.
>> 
>> Giulio
>> 
>>> On 23 Jun 2017, at 01:33, Alexandre Torres Porres  wrote:
>>> 
>>> Hi, I'm testing the usage of externals with libpd, sarting with the ones 
>>> that come with Pd, like [bob~].
>>> 
>>> I'm using libpd for android. I'm on a MacOS Sierra, and using Android 
>>> Studio's emulator. I made it through Rafael's tutorial 
>>> https://www.youtube.com/watch? v=cinOFA1pT1k= 
>>> PLn3ODBv0ka5hS5areRFSTi2aydPMi Uq3B - I got a simple patch that turns on by 
>>> a switch. The emulator uses a Nexus 5 API 24, x86 architecture. So now I 
>>> just have another simple patch with [noise~] going through [bob~] that I 
>>> wanted to try and make it happen. 
>>> 
>>> So, [bob~] is an extra, and you don't get it by default in libpd, so it 
>>> seems. I checked around, and was able to compile pd's extra as .so files. 
>>> In my projects PdCore I got a libs folder with all these compiled externals 
>>> for armeabi / armeabi-v7a / x86! The binary for bob seems to be 
>>> "libbob_tilde.so". But having this is not enough for loading it and playing 
>>> it... what else am I missing?
>>> 
>>> I also did try using PdBase.addToSearchPath  in my code in 
>>> MainActivity.java, I got the idea that would do it, but it didn't, here's 
>>> how I tried it.
>>> 
>>> private void initPD() throws IOException{
>>> int sampleRate = AudioParameters.suggestSampleR ate();
>>> PdAudio.initAudio(sampleRate, 0, 2, 8, true);
>>> 
>>> PdBase.addToSearchPath("/ Users/porres/Desktop/ 
>>> LearningLibPd/HelloPd/PdCore/ libs/x86");
>>> 
>>> dispatcher = new PdUiDispatcher();
>>> PdBase.setReceiver(dispatcher) ;
>>> } 
>>> 
>>> cheers
>>> __ _
>>> Pd-list@lists.iem.at mailing list
>>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/ 
>>> listinfo/pd-list
> 
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] using bob~ with libpd for android

[Giulio Moro via Pd-list]

I have no idea how you build libpd for Android (I also assume that you are 
building it yourself).
When I build it for Linux I do something like:
`make EXTRA=true <>`
that flag `EXTRA=true` makes sure that the extras are compiled and linked into 
the `libpd.so` file.I hope the above can be somehow translated into the system 
you are using to build libpd for Android.
Best,Giulio

  From: Alexandre Torres Porres 
 To: Giulio Moro  
Cc: "pd-list@lists.iem.at" 
 Sent: Friday, 23 June 2017, 3:10
 Subject: Re: [PD] using bob~ with libpd for android
   
> I think you need to make libpd with EXTRA=true or something
sorry, I'm really a dummy in this field, I need more detailed steps, information
thanks
2017-06-22 21:54 GMT-03:00 Giulio Moro :

I think you need to make libpd with EXTRA=true or something like that in order 
to include the extras in the libpd library file without need for extra files.Or 
at least that's how it works on linux/mac, no idea about android.
Just double check in the build log that bob~.o actually gets compiled and 
linked in.
Giulio
On 23 Jun 2017, at 01:33, Alexandre Torres Porres  wrote:


Hi, I'm testing the usage of externals with libpd, sarting with the ones that 
come with Pd, like [bob~].
I'm using libpd for android. I'm on a MacOS Sierra, and using Android Studio's 
emulator. I made it through Rafael's tutorial https://www.youtube.com/watch? 
v=cinOFA1pT1k= PLn3ODBv0ka5hS5areRFSTi2aydPMi Uq3B - I got a simple patch 
that turns on by a switch. The emulator uses a Nexus 5 API 24, x86 
architecture. So now I just have another simple patch with [noise~] going 
through [bob~] that I wanted to try and make it happen. 
So, [bob~] is an extra, and you don't get it by default in libpd, so it seems. 
I checked around, and was able to compile pd's extra as .so files. In my 
projects PdCore I got a libs folder with all these compiled externals for 
armeabi / armeabi-v7a / x86! The binary for bob seems to be "libbob_tilde.so". 
But having this is not enough for loading it and playing it... what else am I 
missing?
I also did try using PdBase.addToSearchPath  in my code in MainActivity.java, I 
got the idea that would do it, but it didn't, here's how I tried it.
private void initPD() throws IOException{
int sampleRate = AudioParameters.suggestSampleR ate();
PdAudio.initAudio(sampleRate, 0, 2, 8, true);

PdBase.addToSearchPath("/ Users/porres/Desktop/ 
LearningLibPd/HelloPd/PdCore/ libs/x86");

dispatcher = new PdUiDispatcher();
PdBase.setReceiver(dispatcher) ;
} 
cheers

__ _
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/ 
listinfo/pd-list





   ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] using bob~ with libpd for android

[Giulio Moro via Pd-list]

I think you need to make libpd with EXTRA=true or something like that in order 
to include the extras in the libpd library file without need for extra files.
Or at least that's how it works on linux/mac, no idea about android.

Just double check in the build log that bob~.o actually gets compiled and 
linked in.

Giulio

> On 23 Jun 2017, at 01:33, Alexandre Torres Porres  wrote:
> 
> Hi, I'm testing the usage of externals with libpd, sarting with the ones that 
> come with Pd, like [bob~].
> 
> I'm using libpd for android. I'm on a MacOS Sierra, and using Android 
> Studio's emulator. I made it through Rafael's tutorial 
> https://www.youtube.com/watch?v=cinOFA1pT1k=PLn3ODBv0ka5hS5areRFSTi2aydPMiUq3B
>  - I got a simple patch that turns on by a switch. The emulator uses a Nexus 
> 5 API 24, x86 architecture. So now I just have another simple patch with 
> [noise~] going through [bob~] that I wanted to try and make it happen. 
> 
> So, [bob~] is an extra, and you don't get it by default in libpd, so it 
> seems. I checked around, and was able to compile pd's extra as .so files. In 
> my projects PdCore I got a libs folder with all these compiled externals for 
> armeabi / armeabi-v7a / x86! The binary for bob seems to be 
> "libbob_tilde.so". But having this is not enough for loading it and playing 
> it... what else am I missing?
> 
> I also did try using PdBase.addToSearchPath in my code in MainActivity.java, 
> I got the idea that would do it, but it didn't, here's how I tried it.
> 
> private void initPD() throws IOException{
> int sampleRate = AudioParameters.suggestSampleRate();
> PdAudio.initAudio(sampleRate, 0, 2, 8, true);
> 
> 
> PdBase.addToSearchPath("/Users/porres/Desktop/LearningLibPd/HelloPd/PdCore/libs/x86");
> 
> dispatcher = new PdUiDispatcher();
> PdBase.setReceiver(dispatcher);
> } 
> 
> cheers
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [OT] pd-announce vs pd-list (was Re: Cyclone 0.3 beta 2 released)

[Giulio Moro via Pd-list]

If they were to post to both lists at the same time, mailman should be clever 
enough to prevent sending duplicated messages to who subscribers that are in 
both lists?
Or at least if mailman is not that clever, many mail clients would be able to 
detect the duplicate and show a single message. But if you send two distinct 
messages, this cannot be filtered out.


Giulio



From: "zmoel...@iem.at" 
To: pd-list@lists.iem.at 
Sent: Monday, 19 June 2017, 20:13
Subject: [PD] [OT] pd-announce vs pd-list (was Re: Cyclone 0.3 beta 2 released)



as you might have noticed, all emails that you send to the pd-announce
mailinglist will automatically get forwarded to pd-list as well.
this is nothing new, it has been in action for more than 11 years [1]
and has since been advertised on the pd-announce info page [2].

the consequence of this behaviour is that if you send announcements to
both pd-announce and pd-list, your announcement will be sent twice to
the pd-list.
i think this is a mild annoyance and i would welcome ideas on who to
prevent people from accidentally doing this.
(it seems to be common enough for people to post to both lists but never
wonder why they receive duplicate announcements).

gfadsmr
IOhannes


[1] https://lists.puredata.info/pipermail/pd-announce/2006-05/000939.html

[2] https://lists.puredata.info/listinfo/pd-announce

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] metro slow down + audio drop-outs

[Giulio Moro via Pd-list]

Pd messages get processed in the audio thread in a sample-accurate fashion. 
This means that if you are sending many messages within the time of the audio 
callback, then your callback will take longer to execute. If the time it takes 
to execute exceeds the time available for it to complete, then you are going to 
get a dropout in the audio. I then believe that Pd's internal "logical time" 
will slow down compared to system time as a consequence of dropping one (or 
more) audio callback.
So you get both glitches and slower metro.

Solution is to throttle your messages: do not send them all at once but add a 
few ms delay between them.

Giulio


From: Nicola Pandini 
To: pd-list@lists.iem.at 
Sent: Friday, 16 June 2017, 11:47
Subject: [PD] metro slow down + audio drop-outs



Hi list,

I have a patch that acts as MIDI master, that sends MTC and other data 

via udpsend to 4 udp ports.

It happens that sometime the patch's audio metronome begin to slow down 

for a bunch of seconds. I also hear cracklings in metronome sound (the 

metronome patch is based on a simple [metro] object).


I don't see any xrun, so I'm starting to think it's a problem of the 

patch. Maybe the buffer of udpsend? Because it seems to happen when I'm 

sending more data than usual (not everytime, though).

Can you give me some hints? I'm using pd-extended on Debian Jessie.


 Thanks


-- 

Nicola



___

Pd-list@lists.iem.at mailing list

UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] messages FROM pd ? ...

[Giulio Moro via Pd-list]

I think the documentation clearly says somewhere something along the lines of 
"to find out more of these, look at the source code for Pd".
Giulio

  From: oliver 
 To: pd-l...@mail.iem.at 
 Sent: Tuesday, 16 May 2017, 17:47
 Subject: [PD] messages FROM pd ? ...
   
hi, dear list !

i know about the messages that can be sent TO pd, but i recently read 
(in the help file for [samplerate~]) that pd sends a bang to a

[receive pd-dsp-started]

object when the dsp is started. of course the same works for

[receive pd-dsp-stopped]

when it is stopped.


that's a nice feature !

are there any other useful messages that can be received by specially 
named receive objects ? (like mouse coordinates, mousestate, window 
coordinates, save state, closing state ...)

there seems to be no documentation on this one ...


best

oliver

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


   ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Is PD using CPU optimisation?

[Giulio Moro via Pd-list]

In many Pd does this already.

https://sourceforge.net/p/pure-data/pure-data/ci/0.47-1/tree/src/d_arithmetic.c?format=raw

see "scalarover_perform" for instance: it computes a single division and then 
runs multiplications in the loop. But I think the compiler would figure out 
this on its own (perhaps with the help of -ffast-math ?).
I guess a  more optimized version would compute the division only when a new 
message is received (as opposed to once every block).
Of course there is not much that can be done for the signal version of [/~].

Compiler optimizations are there, at least in part.
https://sourceforge.net/p/pure-data/pure-data/ci/637ef74e1745a658c0cfdc40d65de189b4fbf02a/tree/configure.acSome
 architectures may require more explicit flags to perform better (e.g.: on ARM 
Cortex, you may want to tell to use -mfpu=neon to enable the use of the faster 
NEON SIMD.

Giulio
From: Dario Sanfilippo 
To: pd-list  
Sent: Wednesday, 8 March 2017, 22:37
Subject: [PD] Is PD using CPU optimisation?



Hello, list.

Would it be sensible to, for example, start using multiplications over 
divisions when possible or will the compiler take care of that?

Cheers,
Dario
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] libpd - Multiple instances of Pd

[Giulio Moro via Pd-list]

Hi,

I was wondering if this is still a wanted feature and if anyone did some 
further work on this beyond what is here 
https://github.com/libpd/libpd/blob/master/samples/c/pdtest_multi/pdtest_multi.c

I peeked through the Pd Vanilla (0.46) source code last night, and I am under 
the impression that in order to allow more instances to coexist in a 
thread-safe way, all it takes is for each instance to have its own copy of 
"t_pdinstance *pd_this"  and for all the calls that currently use the global 
pd_this to take an additional argument "
t_pdinstance *pd_that".
But I also think that if it was that easy, someone else would have tried 
already.
So, before I dig into it just to hit a well known limitation, does anyone want 
to share their experience?


Thanks,
Giulio

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] netsend/netreceive questions ...

[Giulio Moro via Pd-list]

> (so the order of data arrival is guaranteed). 

Well this is a design feature of UDP: there is no guarantee of whether packets 
are going to be received or in what order. If you use UDP, you MUST write your 
program in such a way that it is resilient to data loss and data order. If you 
don't, then you may encounter problems later down the line, when you are in 
less than ideal conditions.
This said, it seems that [mrpeach/net] is designed in such a way that 
out-of-order delivery occurs more often than with other systems. Good to test 
the resiliency of your system.
My brief experience with net objects (I could be wrong, but this is what I 
remember):
[netreceive] / [netsend]: they do the socket job in the audio thread. This 
gives the following deterministic behaviour: the message is written to the 
socket before the audio callback is performed. What it does not give is any 
deterministic guarantee about when the packet is going to go out of your 
interface or be delivered. So given the latter, I am not sure why the former 
matters.
[iemnet/udpsend] / [iemnet/updreceive]: threaded, for [udpsend] the packets are 
stored in memory from the audio thread. A worker thread reads them and writes 
them to the socket. Issue is the audio thread uses malloc() to store the stash 
the values in memory, so it may occasionally hang while waiting for the kernel 
to provide more memory.
[mrpeach/net] have not looked at the code in person, but it has been mentioned 
here that it uses multiple working threads. If threads are created within the 
audio thread (as opposed to using a fixed pool of workers that get "activated" 
from the audio thread), then this also will occasionally hang while waiting for 
the kernel.
None of the approaches above is workable on the platform I am working on 
(Bela), as - running under Xenomai - the usual constraints that apply to audio 
programming (no I/O, no allocation, no creating threads in the audio thread) 
are even more strict (i.e.: you REALLY need to follow these principles).My 
tentative approach was to turn [netreceive] into a threaded object, using a 
lock-free queue beween the threads (the one provided by libpd), using ifdefs to 
reuse most of the existing vanilla code. 
https://github.com/giuliomoro/pure-data/commits/Bela-net
I am not quite happy with it yet: the code looks like a mess with all the 
ifdefs, and [netsend] is not working atm, but [netreceive] now can be safely 
used. I guess it would be better if I were to package it as an external, 
removing the ifdefs.
Giulio

  From: Roman Haefeli 
 To: pd-list@lists.iem.at 
 Sent: Wednesday, 22 February 2017, 15:19
 Subject: Re: [PD] netsend/netreceive questions ...
   
On Mit, 2017-02-22 at 15:41 +0100, IOhannes m zmoelnig wrote:

> mrpeach/net should block less than the built-in object, but in theory
> it
> might still block when spinning up to many threads.
> also mrpeach/net is prone to race-conditions, where one sending
> thread
> can overtake another sending thread (so the order of data arrival is
> not
> guaranteed). obviously mrpeach/net doesn't always exihibit that
> problem
> (else nobody would use it), but iirc i was able to trigger that
> behaviour in a lab situtation.

netpd - as an example of a non-lab situation - does trigger such
problems with mpreach/net. Last time I checked, it presented incoming
data as lists which suggests that it uses some auto-magic internal
delimiting function, but it does not, it relies on pure chance. It's a
misconception that the author refuses to address. 

As far as I can tell, mrpeach/net suffers issues that iemnet does not.
I don't see any advantage in using mrpeach/net besides the fact that
Pd-l2ork / Purr Data - due to their Pd-extended heritage - come with
mrpeach and not with iemnet. 

Roman
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


   ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] test audio signals: Are there <~ and >~ objects?

[Giulio Moro via Pd-list]

> I don't know why [expr~] is usually not considered vanilla

Maybe because it lives in extra/ instead of src/ ?

What is extra/ there for, by the way? I remember it being mentioned in msp's 
paper that introduced [pd~], but not sure why it is still there.
Giulio



From: Alexandre Torres Porres 
To: "pd-list@lists.iem.at"  
Sent: Monday, 6 February 2017, 17:13
Subject: Re: [PD] test audio signals: Are there <~ and >~ objects?


2017-02-06 11:00 GMT-02:00 Peter P. : 
Thanks IOhannes and Roman! Funny there are no internal objects for this.
>best, P
>

[expr~] is an internal 

2017-02-06 11:11 GMT-02:00 cyrille henry :
for a vanilla only solution, you can use tabread~ with a 2 point table...
>

I don't know why [expr~] is usually not considered vanilla

the vanilla solution is with [expr~], which is an internal in vanilla


cheers

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Block staggering

[Giulio Moro via Pd-list]

you may want to have a look at these recent discussions on this 
list:https://lists.puredata.info/pipermail/pd-list/2016-10/116830.html
https://lists.puredata.info/pipermail/pd-list/2016-09/116315.html

Giulio

 
  From: Matt Barber 
 To: PD-List  
 Sent: Monday, 7 November 2016, 16:52
 Subject: [PD] Block staggering
   
Hi list,
This must've come up before, but I can't find it on search.
Is there a reliable way to stagger large block computation so that the load is 
spread across ticks rather than spiking? Does it matter? I'm thinking of this 
classic configuration, where each block is calculated right before the X:

X X X X X X X X X X X X X  X   X   X   X   X   X    X   
    X       X        X               X

Rather than:
X
X X X X X X X X X X X X XX   X   X   X   X   X   XX       X       X       XX    
           X
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


   
 ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] Does libpd know how many adc~ / dac~ channels are in use?

[Giulio Moro via Pd-list]

On our system we need to "prepare" (de-interleave/resample) the input/output 
channels that are passed to libpd.The user may not be using all the I/Os 
available in their patch.Is there a way to get from libpd the number of 
adc~/dac~ channels actually in use by the current Pd patch?
This way we could save some CPU and memory for those channels that are not in 
use in the currently loaded patch.
Thanks,Giulio___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Weird issue: need to increase Pd latency in FFT patches, otherwise Pd sound output glitches and clocks are slowing down!!!

[Giulio Moro via Pd-list]

It sounds like a design feature. The computation of re-blocked subpatches is 
not spread evenly over time, but it is carried out as fast as possible whenever 
the "clock ticks". The CPU usage is low on average, but there are spikes (on 
those sample blocks when all the ffts are computed) that prevent you from 
meeting some of the deadlines. Changing Pd's latency provides more buffering 
against those spikes.
I guess [pd~] may help towards alleviating those problems: 
http://www.pdpatchrepo.info/hurleur/multiprocessing.pdf 
I started a discussion on the topic here 
https://lists.puredata.info/pipermail/pd-list/2016-09/116315.html

 
  From: Christof Ressi 
 To: Christof Ressi ; pd-list  
 Sent: Monday, 31 October 2016, 14:19
 Subject: Re: [PD] Weird issue: need to increase Pd latency in FFT patches, 
otherwise Pd sound output glitches and clocks are slowing down!!!
   
OK, some updates:

obviously it doesn't have to be FFTs, in block-glitch1.pd I replaced the FFTs 
with square roots. But it's neither related to the number of block~ objects or 
subpatches. In block-glitch2.pd, I have a single blocked subpatch with lots of 
square roots and I get the same result. Again, the CPU load is not the problem. 
It seems the problem is merely related to reblocking, overlap and upsampling.  

> Gesendet: Montag, 31. Oktober 2016 um 14:38 Uhr
> Von: "Christof Ressi" 
> An: pd-list 
> Betreff: [PD] Weird issue: need to increase Pd latency in FFT patches, 
> otherwise Pd sound output glitches and clocks are slowing down!!!
>
> Hi, 
> 
> I have the following issue with Pd 0.47.1 on Win 7 (onboard soundcard + 
> ASIO4ALL and also Focusrite Scarlett 6i6 + Focusrite ASIO Driver):
> 
> When I use more than just a few FFTs anywhere in my patch, I get a staggering 
> sound output + clicks from Pd unless I increase the Pd latency... Apparently, 
> it's only the playback because I couldn't hear it in a recording I made with 
> [writesf~]. Therefore I made a recording in Reaper to show you what I'm 
> hearing.
> 
> The more FFTs and the larger the FFT blocksize, the larger I have to set the 
> latency. This even happens if the CPU load is as little as 5% (where 25% 
> would be the maximum for one hardware thread on my laptop). 
> 
> In my test patch, I put a couple of FFT subpatches and a single sine wave 
> with a volume control to check the sound output. Usually, I can play a sine 
> wave without artifacts as long as the CPU load is not peeking. But here, the 
> FFTs seem to magically disturb the audio output of the whole patch...
> 
> I think there's something going wrong with the scheduler because also objects 
> like [metro] and [line] start to go slower - sometimes up to 50%!
> 
> What is going on!?
> 
> Christof___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list
> 
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


   
 ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Threading in Pd/libpd

[Giulio Moro via Pd-list]

Just the opposite, the idea is actually to avoid revising all existing objects, 
that's why I'd rather want to create variations on [block~] / [switch~] that 
support threading for all of the objects in the subpatch.
Giulio




 From: Jonathan Wilkes 
 To: Giulio Moro ; Pd-List  
 Sent: Monday, 3 October 2016, 16:56
 Subject: Re: [PD] Threading in Pd/libpd
   
> Subpatches with the same or smaller block size as the parent patch should not 
> be threaded.

> Subpatches with larger blocksize should be threaded, but it's left up to the 
> user to enable that.
Do you have to revise every single signal object in order for this to work?
-Jonathan
   

   
 ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Threading in Pd/libpd

[Giulio Moro via Pd-list]

Subpatches with the same or smaller block size as the parent patch should not 
be threaded.Subpatches with larger blocksize should be threaded, but it's left 
up to the user to enable that.


 
  From: Jonathan Wilkes 
 To: Giulio Moro ; Pd-List  
 Sent: Saturday, 1 October 2016, 6:08
 Subject: Re: [PD] Threading in Pd/libpd
   



> The entire subpatch, which in principle can be used to wrap [fft~].> My plan 
> is to have a common way of wrapping these objects with threads so that 
> I do not have to re-write all of them.
Would this potentially benefit any subpatch, or just ones that have a 
substantially larger block size than the parent patch?

> Giulio

 
  From: Jonathan Wilkes 
 To: Giulio Moro ; Pd-List  
 Sent: Saturday, 1 October 2016, 1:43
 Subject: Re: [PD] Threading in Pd/libpd
  
> Yes, that's the plan, by default I'd set it to the number of samples 
> corresponding to the step determined by the specified overlap.
What exactly gets computed in the separate thread?  Is it only the revised 
[fft~] object?  Or is it the entire subpatch?
-Jonathan


   

   
 

   

   
 ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Threading in Pd/libpd

[Giulio Moro via Pd-list]

The entire subpatch, which in principle can be used to wrap [fft~].My plan is 
to have a common way of wrapping these objects with threads so that I do not 
have to re-write all of them.
Giulio

 
  From: Jonathan Wilkes 
 To: Giulio Moro ; Pd-List  
 Sent: Saturday, 1 October 2016, 1:43
 Subject: Re: [PD] Threading in Pd/libpd
   
> Yes, that's the plan, by default I'd set it to the number of samples 
> corresponding to the step determined by the specified overlap.
What exactly gets computed in the separate thread?  Is it only the revised 
[fft~] object?  Or is it the entire subpatch?
-Jonathan


   

   
 ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] purr data beta1

[Giulio Moro via Pd-list]

interesting, can you please elaborate on  this:


> Its design principle is centered around nimble distributed development which 
> may (and already does) include improvements in core behavior. 

thanks
Giulio
>
> From: Ivica Bukvic 
>To: Dan Wilcox  
>Cc: Pd-list 
>Sent: Thursday, 29 September 2016, 20:28
>Subject: Re: [PD] purr data beta1
> 
>
>
>I think it can only be spiritual successor if you believe it to be one in part 
>because its philosophy is different. What I said originally was that I had no 
>explicit intentions on replacing extended in part because I was not sure what 
>was its roadmap and whether it had a chance of being developed further. In 
>other words, I never denied its capacity to replace extended but also did not 
>want to assert that in any kind of authoritative way. Hope this helps!
>-- 
>Ivica Ico Bukvic, D.M.A.
>Associate Professor
>Computer Music
>ICAT Senior Fellow
>Director -- DISIS, L2Ork
>Virginia Tech
>School of Performing Arts – 0141
>Blacksburg, VA 24061
>(540) 231-6139
>i...@vt.edu
>www.performingarts.vt.edu
>disis.icat.vt.edu
>l2ork.icat.vt.edu
>ico.bukvic.net
>
>
>On Sep 29, 2016 14:52, "Dan Wilcox"  wrote:
>
>In this light, is Purr Data the spiritual successor for Pd-Extended? As I 
>recall in previous discussions, y'all were explicit that Pd-L2Ork was not.
>>
>>
>>This question is not meant as a slight in any way. I’m just curious how this 
>>new project fits within your goals and the Pd community at large.
>>
>>
>>
>>
>>Dan Wilcox
>>@danomatika
>>danomatika.com
>>
>>robotcowboy.com
>>
>>On Sep 29, 2016, at 12:29 PM, pd-list-requ...@lists.iem.at wrote:
>>>
>>>From: Alexandre Torres Porres 
>>>
>>>Subject: Re: [PD] purr data beta1
>>>
>>>Date: September 29, 2016 at 11:21:49 AM MDT
>>>
>>>To: "pd-list@lists.iem.at" 
>>>
>>>
>>>
>>>
>>>In short: A Game Changer!
>>>
>>>
>>>2016-09-29 13:06 GMT-03:00 Ivica Ico Bukvic :
>>>
>>>Purr-Data is a GUI rewrite for Pd-L2Ork which has over 1,500 
>>>patches/bugfixes/improvements over vanilla/extended. Its design principle is 
>>>centered around nimble distributed development which may (and already does) 
>>>include improvements in core behavior. Hope this helps!

Best,
Ico
>>
>
>___
>Pd-list@lists.iem.at mailing list
>UNSUBSCRIBE and account-management -> 
>https://lists.puredata.info/listinfo/pd-list
>
>
>

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] purr data beta1

[Giulio Moro via Pd-list]

Jonathan,I struggle a bit to understand what is the end goal of Purr Data:as 
far as I can tell, right now it is a re-implementation of the existing GUI in 
HTML5, which is great.Once this process is done (and I see we are very close 
now), how do you see the project will evolve? Will it just be about making the 
GUI more portable/customizable or do you foresee changes in the GUI/dsp 
communication protocol as well?
Best,Giulio

 
  From: Alexandre Torres Porres 
 To: Jonathan Wilkes  
Cc: Pd-List 
 Sent: Thursday, 29 September 2016, 7:12
 Subject: Re: [PD] purr data beta1
   
awesome, more and more excited at each new development step
so, Scope~ is already ported, but [comment]  is not working yet, are you 
dealing with it?
cheers
2016-09-29 1:51 GMT-03:00 Jonathan Wilkes via Pd-list :

This is the beta 1 release of Purr Data (the GUI port of Pd-l2ork)

Change log:
* fix many errors in the GUI
* fix position of popup menu when zooming
* fix scalar crasher
* fix gop display error
* fix disappearing $@
* save gui preset with preferences
* fix segfault with preference changes
* fixed many memory leaks with patches backported from Pd Vanilla
* small fixes to help patches
* add text editor window for [text define]
* add and improve the scalar properties dialog
* add default float arg for Pd's "quit" message (good for test patches)
* updated some external libraries

This is a beta release, so please report lots of bugs to
https://git.purrdata.net/ jwilkes/purr-data/issues

Binaries here:
https://git.purrdata.net/ jwilkes/purr-data-binaries/ tree/master
-Jonathan

__ _
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/ 
listinfo/pd-list




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


   
 ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Threading in Pd/libpd

[Giulio Moro via Pd-list]

>> With a 
>> threaded implementation, you could add a delay for that specific subpatch 
>> instead of the whole of Pd.
> I'm having trouble seeing how that would work in practice.
> Would the user specify the delay in ms/blocks as an argument?

Yes, that's the plan, by default I'd set it to the number of samples 
corresponding to the step determined by the specified overlap.

Giulio
>
> From: Jonathan Wilkes 
>To: Giulio Moro ; Pd-List  
>Sent: Thursday, 29 September 2016, 2:33
>Subject: Re: [PD] Threading in Pd/libpd
>
>> So having a look at the source code I'd say what would happen is that 
>
>> the second block prints the samples of the sound file.
>
>> I guess the point you are trying to make here is that a threaded version 
>
>> of [fft~], the perform routing should block if the samples are not ready in 
>
>> time. That sounds perfectly plausible (and doable) to me.
>> Or am I missing your point?
>
>That's right.  But on the broader scale I'm pointing out how easy it is to 
>overlook determinism in these cases.
>
>> I'd add that right now, if the system cannot compute an FFT on time and it 
>
>> causes dropouts, you have to solve that by increasing Pd's delay. With a 
>> threaded implementation, you could add a delay for that specific subpatch 
>> instead of the whole of Pd.
>
>I'm having trouble seeing how that would work in practice.  Would the 
>user specify the delay in ms/blocks as an argument?


>> Giulio
>
>
>
>>
>> From: Jonathan Wilkes 
>>To: Giulio Moro ; Pd-List  
>>Sent: Wednesday, 28 September 2016, 23:00
>>Subject: Re: [PD] Threading in Pd/libpd
>>
>>
>>
>>> Thanks Jonathan.
>>
>>
>>> Also [readsf~] supports threading and so do [udpsend] and [udpreceive], for 
>>> obvious reasons involving system calls.
>>
 Can you guarantee that the revisions you've implemented generate the same 
 output as Pd Vanilla, for all cases?
>>
>>
>>> I'd rather say it does not, in all cases. At the very least there is going 
>>> to be a delay involved. But, if this brings to a different behaviour, yet 
>>> still deterministic, would that be bad? After all, the above mentioned 
>>> objects are not deterministic themselves, yet they are widely used, with a 
>>> very high success rate.
>>
>>
>>udpsend and udpreceive are special cases because the protocol itself rules 
>>out the kind of determinism we're discussing. 
>>
>>
>>
>>So let's focus on readsf~ instead.
>>
>>
>>Suppose readsf~ is reading a sound file and outputs 3 blocks-- block 1, block 
>>2, and block 3.  The patch is outputting the sound file to the sound card, so 
>>we are 
>>
>>listening to the sound file as Pd is running.
>>
>>
>>Now, imagine this happens:
>>
>>
>>1st block: readsf~ perform routine finishes in time to output a block to the 
>>soundcard on schedule.
>>
>>2nd block: perform routine takes longer to compute, and it misses the 
>>deadline set for the next block to be delivered to the soundcard.  So we hear 
>>a dropout.
>>3rd block: perform routine finishes in time to meet the deadline.
>>
>>
>>Now, suppose we were debugging our patch by outputting each block of samples 
>>
>>to the console.  Here's the question, then: what gets printed for the 2nd 
>>block?  
>>
>>Does Pd print out the samples from the sound file that missed the deadline, 
>>or 
>>
>>does it print out 64 zeroes?
>>
>>
>>-Jonathan
>>
>>
>>
>>
>>
>>
>
>
>
>
>

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Threading in Pd/libpd

[Giulio Moro via Pd-list]

So having a look at the source code I'd say what would happen is that the 
second block prints the samples of the sound file.
I guess the point you are trying to make here is that a threaded version of 
[fft~], the perform routing should block if the samples are not ready in time. 
That sounds perfectly plausible (and doable) to me.Or am I missing your point?
I'd add that right now, if the system cannot compute an FFT on time and it 
causes dropouts, you have to solve that by increasing Pd's delay. With a 
threaded implementation, you could add a delay for that specific subpatch 
instead of the whole of Pd.
Giulio
 
  From: Jonathan Wilkes 
 To: Giulio Moro ; Pd-List  
 Sent: Wednesday, 28 September 2016, 23:00
 Subject: Re: [PD] Threading in Pd/libpd
   
> Thanks Jonathan.

> Also [readsf~] supports threading and so do [udpsend] and [udpreceive], for 
> obvious reasons involving system calls.

>> Can you guarantee that the revisions you've implemented generate the same 
>> output as Pd Vanilla, for all cases?

> I'd rather say it does not, in all cases. At the very least there is going to 
> be a delay involved. But, if this brings to a different behaviour, yet still 
> deterministic, would that be bad? After all, the above mentioned objects are 
> not deterministic themselves, yet they are widely used, with a very high 
> success rate.
udpsend and udpreceive are special cases because the protocol itself rules out 
the kind of determinism we're discussing. 

So let's focus on readsf~ instead.
Suppose readsf~ is reading a sound file and outputs 3 blocks-- block 1, block 
2, and block 3.  The patch is outputting the sound file to the sound card, so 
we are 
listening to the sound file as Pd is running.
Now, imagine this happens:
1st block: readsf~ perform routine finishes in time to output a block to the 
soundcard on schedule.
2nd block: perform routine takes longer to compute, and it misses the deadline 
set for the next block to be delivered to the soundcard.  So we hear a 
dropout.3rd block: perform routine finishes in time to meet the deadline.
Now, suppose we were debugging our patch by outputting each block of samples 
to the console.  Here's the question, then: what gets printed for the 2nd 
block?  
Does Pd print out the samples from the sound file that missed the deadline, or 
does it print out 64 zeroes?
-Jonathan


   

   
 ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Threading in Pd/libpd

[Giulio Moro via Pd-list]

Thanks Jonathan.

Also [readsf~] supports threading and so do [udpsend] and [udpreceive], for 
obvious reasons involving system calls.

> Can you guarantee that the revisions you've implemented generate the same 
> output as Pd Vanilla, for all cases?


I'd rather say it does not, in all cases. At the very least there is going to 
be a delay involved. But, if this brings to a different behaviour, yet still 
deterministic, would that be bad? After all, the above mentioned objects are 
not deterministic themselves, yet they are widely used, with a very high 
success rate. And what happens if you realize your [readsf~] glitches ? You 
change your code so that it sends the [open( message earlier on. As the objects 
I am talking about ( fft~, fiddle~, sigmund~) do not rely on system calls, I 
expect their behaviour to be more predictable than that of, e.g.: [readsf~].
I think I'll see if I can put together a [blockthread~] object which can do 
something useful.

Best,
Giulio


> From: Jonathan Wilkes 
>To: Giulio Moro ; Pd-List  
>Sent: Tuesday, 27 September 2016, 18:35
>Subject: Re: [PD] Threading in Pd/libpd
> 
>
>
>> So, probably this point has been discussed previously, I'd like to know:
>> - are there any existing objects doing this already?
>
>
>There is a creation argument to [coll] in Pd-l2ork that enables threading.
>
>
>
>
>
>> - what are the pitfalls that prevented such an approach from making its way 
>> into Pd?
>
>
>The second biggest pitfall is that such an approach can easily (and subtly) 
>break determinism.
>
>
>The biggest pitfall is overestimating the benefit of the performance gains to 
>the detriment of 
>
>determinism.  Can you guarantee that the revisions you've implemented generate 
>the same 
>
>output as Pd Vanilla, for all cases?
>
>
>- how can I help?
>
>
>A good place to start might be regression tests for block~.  I'd especially 
>look at cases that 
>
>use vline~ in conjunction with it, using very small delays, and make sure that 
>you are getting 
>
>the exact same samples output using your revised objects.
>
>
>-Jonathan
>
>
>
>
>
>
>

>>From: Giulio Moro 
>>To: Pd-List  
>>Sent: Sunday, 18 September 2016, 2:23
>>Subject: Threading in Pd/libpd
>>
>>
>>
>>Hi all,
>>if I understand correctly, using the [block~] and [switch~] objects to 
>>increase the blocksize for a given subpatch, means that the DSP computation 
>>for that subpatch is delayed until the moment when enough input samples have 
>>been collected, at which point the entire DSP stack for the subpatch is 
>>performed at once and the outputs are written to the output buffer.
>>This means that the DSP load is not spread over time, rather it is 
>>concentrated in that single audio driver callback when the buffer for that 
>>subpatch happens to be ready to be processed.
>>
>>
>>Now, if what I say makes sense, then this approach has the disadvantage that 
>>the CPU load is not spread evenly across audio callbacks, eventually causing 
>>dropouts if whatever computation takes too long in that one callback, forcing 
>>you to increase the internal buffering of Pd (``Delay'') to cope with this. 
>>At the same time, though, the CPU will be pretty much idle in all the other 
>>audio callbacks.
>>
>>
>>If we could spread the load of the expensive, but occasional, computation 
>>(say fft) over multiple audio callbacks, then the CPU load would be more 
>>even, with no spikes and there would be no need to increase Pd's internal 
>>buffering.
>>This would require to have the output of the fft available a few processing 
>>blocks after the one where it was started, while the current approach allows 
>>to have it immediately available. A fine tuning of the system would be 
>>required to understand how much this latency should be, and worst case it 
>>would be the number of overlap samples as set by [block~] (as in: if the 
>>system cannot process these blocks fast enough, then you should lower your 
>>requirements, as your system cannot provide the required throughput). Now 
>>this may seem a downside, but the actual overall roundtrip latency of the Pd 
>>subpatch would be not much larger than the one currently achievable (if at 
>>all larger), with the added advantage that the rest of Pd could work at 
>>smaller blocksizes, and with a ``Delay'' set to 0.
>>The ultimate advantage would be to have a more responsive system, in terms of 
>>I/O roundtrip for most of the patch, except those subpatches where a longer 
>>latency is anyhow imposed by the algorithm. Think for instance of having a 
>>patch processing the live the sound of an instrument, which also uses 
>>[sigmund~] to detect its pitch to apply some adaptive effect. A low roundtrip 
>>latency could be used for the processed instrument while the latency imposed 
>>by [sigmund~] would only affect e.g.: the parameters of the effect. I see how 

Re: [PD] Threading in Pd/libpd

[Giulio Moro via Pd-list]

It looks like I am not very lucky in getting attention, so let me try to re-up 
this. Can we implement a threaded [block~] ? see details below


 
  From: Giulio Moro 
 To: Pd-List  
 Sent: Sunday, 18 September 2016, 2:23
 Subject: Threading in Pd/libpd
   
Hi all,if I understand correctly, using the [block~] and [switch~] objects to 
increase the blocksize for a given subpatch, means that the DSP computation for 
that subpatch is delayed until the moment when enough input samples have been 
collected, at which point the entire DSP stack for the subpatch is performed at 
once and the outputs are written to the output buffer.This means that the DSP 
load is not spread over time, rather it is concentrated in that single audio 
driver callback when the buffer for that subpatch happens to be ready to be 
processed.
Now, if what I say makes sense, then this approach has the disadvantage that 
the CPU load is not spread evenly across audio callbacks, eventually causing 
dropouts if whatever computation takes too long in that one callback, forcing 
you to increase the internal buffering of Pd (``Delay'') to cope with this. At 
the same time, though, the CPU will be pretty much idle in all the other audio 
callbacks.
If we could spread the load of the expensive, but occasional, computation (say 
fft) over multiple audio callbacks, then the CPU load would be more even, with 
no spikes and there would be no need to increase Pd's internal buffering.This 
would require to have the output of the fft available a few processing blocks 
after the one where it was started, while the current approach allows to have 
it immediately available. A fine tuning of the system would be required to 
understand how much this latency should be, and worst case it would be the 
number of overlap samples as set by [block~] (as in: if the system cannot 
process these blocks fast enough, then you should lower your requirements, as 
your system cannot provide the required throughput). Now this may seem a 
downside, but the actual overall roundtrip latency of the Pd subpatch would be 
not much larger than the one currently achievable (if at all larger), with the 
added advantage that the rest of Pd could work at smaller blocksizes, and with 
a ``Delay'' set to 0.The ultimate advantage would be to have a more responsive 
system, in terms of I/O roundtrip for most of the patch, except those 
subpatches where a longer latency is anyhow imposed by the algorithm. Think for 
instance of having a patch processing the live the sound of an instrument, 
which also uses [sigmund~] to detect its pitch to apply some adaptive effect. A 
low roundtrip latency could be used for the processed instrument while the 
latency imposed by [sigmund~] would only affect e.g.: the parameters of the 
effect. I see how this approach may be useful in many cases.Multi-core hardware 
would take extra advantage from this way of spreading the CPU usage.
I am in the situation where I hacked together a threaded version of [sigmund~] 
for use with libpd on Bela which works fine and I am wondering if it is worth 
going down the route of making threaded versions of all objects with similar 
requirements (which I really would not want to do) or I should rather try to 
create some higher-level objects (say [blockThread~] ) that perform the 
threading strategy mentioned above.It may be that [pd~] could probably(?) 
provide the solution requested, but it seems to me there is lots of overhead 
associated with it, and I do not see how to easily integrate it with our use of 
libpd.
So, probably this point has been discussed previously, I'd like to know:- are 
there any existing objects doing this already?- what are the pitfalls that 
prevented such an approach from making its way into Pd?- how can I help?
Best,Giulio   
 ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] Threading in Pd/libpd

[Giulio Moro via Pd-list]

Hi all,if I understand correctly, using the [block~] and [switch~] objects to 
increase the blocksize for a given subpatch, means that the DSP computation for 
that subpatch is delayed until the moment when enough input samples have been 
collected, at which point the entire DSP stack for the subpatch is performed at 
once and the outputs are written to the output buffer.This means that the DSP 
load is not spread over time, rather it is concentrated in that single audio 
driver callback when the buffer for that subpatch happens to be ready to be 
processed.
Now, if what I say makes sense, then this approach has the disadvantage that 
the CPU load is not spread evenly across audio callbacks, eventually causing 
dropouts if whatever computation takes too long in that one callback, forcing 
you to increase the internal buffering of Pd (``Delay'') to cope with this. At 
the same time, though, the CPU will be pretty much idle in all the other audio 
callbacks.
If we could spread the load of the expensive, but occasional, computation (say 
fft) over multiple audio callbacks, then the CPU load would be more even, with 
no spikes and there would be no need to increase Pd's internal buffering.This 
would require to have the output of the fft available a few processing blocks 
after the one where it was started, while the current approach allows to have 
it immediately available. A fine tuning of the system would be required to 
understand how much this latency should be, and worst case it would be the 
number of overlap samples as set by [block~] (as in: if the system cannot 
process these blocks fast enough, then you should lower your requirements, as 
your system cannot provide the required throughput). Now this may seem a 
downside, but the actual overall roundtrip latency of the Pd subpatch would be 
<= the one currently achievable, with the added advantage that the rest of Pd 
could work at smaller blocksizes and without the additional ``Delay'' required 
in the current configuration.The ultimate advantage would be to have a more 
responsive system, in terms of I/O roundtrip for most of the patch, except 
those subpatches where a longer latency is imposed by the algorithm. Think for 
instance of having a patch processing the live the sound of an instrument, 
which also uses [sigmund~] to detect its pitch to apply some adaptive effect. A 
low roundtrip latency could be used for the processed instrument while the 
latency imposed by [sigmund~] would only affect e.g.: the parameters of the 
effect. I see how this approach may be useful in many cases.Multi-core hardware 
would take extra advantage from this way of spreading the CPU usage.
I am in the situation where I hacked together a threaded version of [sigmund~] 
for use with libpd on Bela which works fine and I am wondering if it is worth 
going down the route of making threaded versions of all objects with similar 
requirements (which I really would not want to do) or I should rather try to 
create some higher-level objects (say [blockThread~] ) that perform the 
threading strategy mentioned above.It may be that [pd~] could probably(?) 
provide the solution requested, but it seems to me there is lots of overhead 
associated with it, and I do not see how to easily integrate it with our use of 
libpd.
So, probably this point has been discussed previously, I'd like to know:- are 
there any existing objects doing this already?- what are the pitfalls that 
prevented such an approach from making its way into Pd?- how can I help?
Best,Giulio___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] bendin bug (?)

[Giulio Moro via Pd-list]

ha! good point!there goes my argument.


 
  From: Alexandre Torres Porres 
 To: Giulio Moro  
Cc: Miller Puckette ; "pd-list@lists.iem.at" 

 Sent: Monday, 12 September 2016, 21:10
 Subject: Re: [PD] bendin bug (?)
   
> didn't want to cause disturbance.
please, this is no disturbance and I don't represent this list any more than 
you do, everything I say is also just my opinion and my two cents
> If we want to abstract from the implementation
well, if we don't then maybe we should have 2 inputs/output for the Most and 
Least significant bits from 0-127, cause that is what the specification is... 
and the '0' point is 64 / 0 
anything else is an abstraction
cheers
2016-09-12 16:52 GMT-03:00 Giulio Moro :

> it is a "weird" inconsistent standardI actually mean it is inconsistent with 
>how the data is represented according to the MIDI standard.
> now i don't know if you're just pushing to make this point, when 3 people 
>already manifested that this sounds reasonable and intuitive as well.
Signed integer surely does sound more intuitive than unsigned integer, I agree. 
My point is, if we want to program for intuitiveness, then normalized float is 
good (possibly with a different rescaling for the positive part, so that -1 ->  
-8192 and 1 -> +8191, either way, it should be clipped to range).
If we want to abstract from the implementation (as both normalized float and 
signed integer do), then I would advocate for the former, as it makes more 
sense altogether. Going for the latter is, in my opinion, not much of an 
improvement over the current situation and I would not bother, ESPECIALLY if it 
is going to be a breaking change. But then, I only recently subscribed to this 
mailing list, so I have no idea what practices are already in place in the 
development of Pd, I was just sharing my opinion on the subject, didn't want to 
cause disturbance.
Best,Giulio
 
  From: Alexandre Torres Porres 
 To: Giulio Moro  
Cc: Miller Puckette ; "pd-list@lists.iem.at" 

 Sent: Monday, 12 September 2016, 20:34
 Subject: Re: [PD] bendin bug (?)
   


2016-09-12 16:14 GMT-03:00 Giulio Moro :


As far as intuitiveness is concerned, -1 to 0.999878 is the most intuitive 
range for me.

You'll be glad to know that the update in cyclone will include also the -1 to 
0.999878 range for you in midiformat/midiparse. I didn't mention, but besides 
-8192 to 8191 they also included this - but there's no  0-16383 option though. 

Just to make a point that intuitiveness is arbitrary.

now i don't know if you're just pushing to make this point, when 3 people 
already manifested that this sounds reasonable and intuitive as well. 
-8192 to 8191 sits somewhere in between, breaks free from the specs and yet is 
not intuitive to use.


but this is widely used and I've seen it in different occasions. for instance, 
it is actually even used in Pd's bendout... why? Cause it is something that 
actually exists! Another example is that it was just introduced in Max's 
midiformat/midiparse instead of the 0-16383 range. I'm sorry but I have to 
disagree that it is a "weird" inconsistent standard. It is actually the only 
standard I ever knew until I found these issues. And it is widely used because 
it is in fact intuitive, 'coz '0' means no pitch bend up or down...  Now, ask a 
newbie what's the middle point in the 0-16383 range?
cheers

   
 



   
 ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] bendin bug (?)

[Giulio Moro via Pd-list]

> it is a "weird" inconsistent standardI actually mean it is inconsistent with 
>how the data is represented according to the MIDI standard.
> now i don't know if you're just pushing to make this point, when 3 people 
>already manifested that this sounds reasonable and intuitive as well.
Signed integer surely does sound more intuitive than unsigned integer, I agree. 
My point is, if we want to program for intuitiveness, then normalized float is 
good (possibly with a different rescaling for the positive part, so that -1 ->  
-8192 and 1 -> +8191, either way, it should be clipped to range).
If we want to abstract from the implementation (as both normalized float and 
signed integer do), then I would advocate for the former, as it makes more 
sense altogether. Going for the latter is, in my opinion, not much of an 
improvement over the current situation and I would not bother, ESPECIALLY if it 
is going to be a breaking change. But then, I only recently subscribed to this 
mailing list, so I have no idea what practices are already in place in the 
development of Pd, I was just sharing my opinion on the subject, didn't want to 
cause disturbance.
Best,Giulio
 
  From: Alexandre Torres Porres 
 To: Giulio Moro  
Cc: Miller Puckette ; "pd-list@lists.iem.at" 

 Sent: Monday, 12 September 2016, 20:34
 Subject: Re: [PD] bendin bug (?)
   


2016-09-12 16:14 GMT-03:00 Giulio Moro :


As far as intuitiveness is concerned, -1 to 0.999878 is the most intuitive 
range for me.

You'll be glad to know that the update in cyclone will include also the -1 to 
0.999878 range for you in midiformat/midiparse. I didn't mention, but besides 
-8192 to 8191 they also included this - but there's no  0-16383 option though. 

Just to make a point that intuitiveness is arbitrary.

now i don't know if you're just pushing to make this point, when 3 people 
already manifested that this sounds reasonable and intuitive as well. 
-8192 to 8191 sits somewhere in between, breaks free from the specs and yet is 
not intuitive to use.


but this is widely used and I've seen it in different occasions. for instance, 
it is actually even used in Pd's bendout... why? Cause it is something that 
actually exists! Another example is that it was just introduced in Max's 
midiformat/midiparse instead of the 0-16383 range. I'm sorry but I have to 
disagree that it is a "weird" inconsistent standard. It is actually the only 
standard I ever knew until I found these issues. And it is widely used because 
it is in fact intuitive, 'coz '0' means no pitch bend up or down...  Now, ask a 
newbie what's the middle point in the 0-16383 range?
cheers

   
 ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] bendin bug (?)

[Giulio Moro via Pd-list]

As far as intuitiveness is concerned, -1 to 0.999878 is the most intuitive 
range for me.Just to make a point that intuitiveness is arbitrary. I would 
encourage to adopt the MIDI specifications and use those numbers [0-16383] OR a 
normalized value -1 to 0.999878. -8192 to 8191 sits somewhere in between, 
breaks free from the specs and yet is not intuitive to use.
I would also advocate that we should not change the behaviour of an object that 
has been there for ages, so a +1 for deprecating [bendin] [bendout] for 
[pitchebendin] [pitchbendout].
MIDI specs are at revision 1.0 and have always been, afaik, so I take it the 
pitch bend always was supposed to be a double precision value. A further 
intuition is: switching from single- to double- precision would have broken all 
existing MIDI devices which implemented running status.
Best,Giulio

 
  From: Alexandre Torres Porres 
 To: Miller Puckette  
Cc: "pd-list@lists.iem.at" 
 Sent: Monday, 12 September 2016, 20:01
 Subject: Re: [PD] bendin bug (?)
   
2016-09-12 15:31 GMT-03:00 Miller Puckette :

In fact I thought there already was one in Cyclone.


The one in cyclone is [xbendin] and [xbendout] and they both go from 0 to 1383. 
I find this pair of objects quite obsolete and I don't know why they were put 
in cyclone, as they don't do anything different than Pd's bendin/bendout - they 
are consistent between themselves though.
Max also has bendin/benout, but the 'x' variance seems to be newer and with a 
different range, cause the old - but still existing - bendin/bendout objects in 
Max are only 7 bits (from 0 to 127). BTW, Miller, can you confirm pitch bend 
messages were only 7 bits back in the day? And do you know when this changed to 
14 bits?
Funny enough, max has inconsistencies with other objects. 
Quite recently, in the 7.2.0 version (Max is now at 7.2.4), the objects 
[midiformat] and [midiparse] were finally updated to include 14 bits pitch bend 
messages, via a '@hires' attribute. The ones in cyclone are still only 7 bits 
(0-127).
We (Me and Derek) just updated these objects in our currently unreleased 
cyclone update project to include 14 bit pitch bend messages. In conjunction 
with Pd's [midiin] / [midiout], they can replace [bendin] / [bendout] related 
objects, but it is just too clumsy for that. And the silly thing is that they 
chose for them the more intuitive range from -8192 to 8191, making it 
inconsistent to xbendin/xbendout. We adopted this more intuitive range anyway.
I was then checking bendin/bendout in Pd to see if they were also from -8192 to 
8191 and then found this inconsistency.
So, in short: yeah; xbendin/xbendout in cyclone can be used for a consistent 
range between MIDI in/output. But then I still think these objects are quite 
obsolete, cause bendin/out are basic elements present in vanilla. And I it is 
also weird to me to have them as a way to replace existing objects in vanilla.
> Yet another idea would be to make a new object name (pitchbendin/out) 

Cool. Whatever the solution is, I'm hoping for a vanilla fix so both pitch bend 
in/out messages are consistent in vanilla. I'm ok with any solution, but I'm 
just hoping that both make use of the more intuitive -8192 to 8191 range.
cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


   
 ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] disable cores on linux to use as dedicated dsp

[Giulio Moro via Pd-list]

In Bela we use it, but the BeagleBone Black is single-core, so we do not run it 
100% CPU because that would prevent Linux from running altogether. My upper 
limit currently is "how much CPU can I use for my audio while I can still be 
ssh'd into the board and nicely SIGINT the process", and that is about 
92.5%.Above that the audio keeps running but the board becomes irresponsive, so 
not very practical to do it while developing (needs a power cycle to stop your 
running program!). Also, not sure how nicely that would play if the kernel does 
not run for many seconds/minutes/hours ... Will have to try it out.
Giulio

 
  From: Simon Iten 
 To: Giulio Moro ; Jonathan Wilkes ; 
Pd-List  
 Sent: Wednesday, 7 September 2016, 21:22
 Subject: Re: [PD] disable cores on linux to use as dedicated dsp
   
 interesting, bela uses this approach! http://bela.io/#about 
  so it should not be that hard to adapt it for desktops and laptops
  
 On 09/07/2016 08:01 PM, Giulio Moro wrote:
  
  I believe the solution to these things lies in using Xenomai or other RT 
extensions for Linux. With Xenomai you take control of the scheduler and you 
can have one process taking up an entire CPU, while the Linux kernel waits ( or 
uses other CPUs). 
  Giulio 
   
  From: Jonathan Wilkes via Pd-list 
 To: Simon Iten ; Pd-List  
 Sent: Wednesday, 7 September 2016, 18:50
 Subject: Re: [PD] disable cores on linux to use as dedicated dsp
  
 > On Wednesday, September 7, 2016 12:51 PM, Simon Iten  
 > wrote:
 
 > hi list,
 
 > i recorded 3 times in a studio last year that uses a daw/pc 
 > interconnection by pyramix, basically it is a hacked windows system, 
 > where one or two cores of a multicore cpu are completely hidden from the 
 > system. these cores are then acessed directly by the daw and used as a 
 > very powerful dsp. the system is incredible! lowest latencies, high 
 > trackcount, and the breakout to the adc/dac is a simple network cable.
 
 > see here for additional info:
 
 > http://www.merging.ch/products/pyramix/masscore
 
 > i since wondered if this would be a way to go for puredata? at least on 
 > linux it seems very easy to deactivate a core (but i don't know if it 
 > than can be used directly by a process) : echo 0 > 
 > /sys/devices/system/cpu/cpu1/online for core2 for example.
 
 
 > is this a completely stupid idea? note that i have no idea how hard it 
 > would be to implement something like this
 
 
 > thanks for any insight
 
 
 Hi Simon,
 That quite an intriguing design.
 
 It hurts my brain too much to try to assess the difficulty of such an 
undertaking to 
 refactor Pure Data to this design.  
 So let me try a shortcut:
 
 Inside d_ugen.c (which is essentially just dsp algos, so there should be few 
if any 
 system calls) I see a t_getbytes call.  t_getbytes calls calloc.
 
 With the design you linked to, do Pd devs have to reimplement malloc?  If the 
answer 
 is yes, then I'd call this a massively difficult undertaking.  If d_* relies 
on the 
 system calls, then you can bet x_*, m_*, s_*, and g_* do, too, and to a much 
greater 
 extent.
 
 If the answer is no, I'd like to learn more about the design.
 
 -Jonathan
 
 ___
 Pd-list@lists.iem.at mailing list
 UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list 
 
 ___
 Pd-list@lists.iem.at mailing list
 UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list
  
 

   
 
 

   
 ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] disable cores on linux to use as dedicated dsp

[Giulio Moro via Pd-list]

I believe the solution to these things lies in using Xenomai or other RT 
extensions for Linux. With Xenomai you take control of the scheduler and you 
can have one process taking up an entire CPU, while the Linux kernel waits ( or 
uses other CPUs).
Giulio
 
  From: Jonathan Wilkes via Pd-list 
 To: Simon Iten ; Pd-List  
 Sent: Wednesday, 7 September 2016, 18:50
 Subject: Re: [PD] disable cores on linux to use as dedicated dsp
   
> On Wednesday, September 7, 2016 12:51 PM, Simon Iten  
> wrote:

> hi list,

> i recorded 3 times in a studio last year that uses a daw/pc 
> interconnection by pyramix, basically it is a hacked windows system, 
> where one or two cores of a multicore cpu are completely hidden from the 
> system. these cores are then acessed directly by the daw and used as a 
> very powerful dsp. the system is incredible! lowest latencies, high 
> trackcount, and the breakout to the adc/dac is a simple network cable.

> see here for additional info:

> http://www.merging.ch/products/pyramix/masscore

> i since wondered if this would be a way to go for puredata? at least on 
> linux it seems very easy to deactivate a core (but i don't know if it 
> than can be used directly by a process) : echo 0 > 
> /sys/devices/system/cpu/cpu1/online for core2 for example.


> is this a completely stupid idea? note that i have no idea how hard it 
> would be to implement something like this


> thanks for any insight


Hi Simon,
That quite an intriguing design.

It hurts my brain too much to try to assess the difficulty of such an 
undertaking to 
refactor Pure Data to this design.  
So let me try a shortcut:

Inside d_ugen.c (which is essentially just dsp algos, so there should be few if 
any 
system calls) I see a t_getbytes call.  t_getbytes calls calloc.

With the design you linked to, do Pd devs have to reimplement malloc?  If the 
answer 
is yes, then I'd call this a massively difficult undertaking.  If d_* relies on 
the 
system calls, then you can bet x_*, m_*, s_*, and g_* do, too, and to a much 
greater 
extent.

If the answer is no, I'd like to learn more about the design.

-Jonathan

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


   
 ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Once again, -guiport -nogui

[Giulio Moro via Pd-list]

thanks,this works for me.
Giulio

 
  From: Miller Puckette <m...@ucsd.edu>
 To: Giulio Moro <giuliom...@yahoo.it> 
Cc: Pd list <pd-list@lists.iem.at>
 Sent: Sunday, 4 September 2016, 16:21
 Subject: Re: [PD] Once again, -guiport -nogui
   
I think this was once possible to do but apparently it isn't possible
any longer.  On the other hand, if you'e trying to connect a pd process
on one computer with a GUI process on another one, that should be doable
using something like 
pd -guicmd "ssh machine-name wish /home/msp/pd/tcl//pd-gui.tcl 5400"

To get this to work you'll need a connection to an ssh agent with permission
to login to the other machine (which should work as long as you can type
"ssh machine-name" on a shell and not have to type the password).  And the
machine you're connecting to mustn't firewall off port 5400, tcp protocol.

One remaining stupid problem: if you hit "open" or "save as" the dialog will
be run from the GUI machine so you'll see all the wrong files on offer unless
you've carefully mirrored the filesystem someho.

cheers
Miller


On Sun, Sep 04, 2016 at 01:01:38PM +, Giulio Moro via Pd-list wrote:
> I am re-upping this as I did not get any response.
>  
>      From: Giulio Moro <giuliom...@yahoo.it>
>  To: Pd list <pd-list@lists.iem.at> 
>  Sent: Monday, 22 August 2016, 12:33
>  Subject: Once again, -guiport -nogui
>    
> Hi,I dug as much as I could into past posts on this topic, like these 
> https://lists.puredata.info/pipermail/pd-list/2007-08/052611.html
> and this https://lists.puredata.info/pipermail/pd-list/2008-05/061978.html
> but I yet have to find the answer to:
> How do Ia) start the GUI with no DSP ?b) start the DSP with no GUI ?c) have 
> the two communicate together nicely?
> So far I have only managed (on Mac OS X) to - start the regular Pd- start a 
> process with -guiport 5400 which connects to the existing GUI- kill the DSP 
> process that came with the GUI, the GUI still runs- at this point, patching 
> in the GUI is very slow and blocks are very small and the text is outside the 
> box- if I try to create [dac~] or [adc~] I get a "couldn't create"
> There must be a better (and working) way of doing this.Once I get it to work 
> on one computer, I believe it should just work when using two computers, 
> right?
> Thanks,Giulio
> 
>    
>  

> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list



   
 ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] bendin bug (?)

[Giulio Moro via Pd-list]

The specs don't say much about how to interpret the value actually 
https://www.midi.org/specifications/item/table-1-summary-of-midi-message

"Pitch Bend Change. 
status: 1110 
data: 0lll 0mmm

This message is sent to indicate a change in the pitch bender (wheel or lever, 
typically). The pitch bender is measured by a fourteen bit value. Center (no 
pitch change) is 2000H. Sensitivity is a function of the transmitter. (ll) 
are the least significant 7 bits. (mm) are the most significant 7 bits."


>
> From: Alexandre Torres Porres 
>To: Giulio Moro  
>Cc: "pd-list@lists.iem.at" 
>Sent: Sunday, 4 September 2016, 19:33
>Subject: Re: [PD] bendin bug (?)
> 
>
>
>
>
>
>
>2016-09-04 13:35 GMT-03:00 Giulio Moro :
>
>Is this a [bendin] or a [bendout]  bug?
>>
>>
>>[bendin]'s current implementation is closer to the actual MIDI messages being 
>>transmitted.
>
>
>but in actuality, the not raw standard is from -8192 to 8191 right?
>
>
>I just care they both are the same, but it seems to me that -8192 to 8191 is 
>the sensible choice
>
>
>cheers
>
>

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] bendin bug (?)

[Giulio Moro via Pd-list]

Is this a [bendin] or a [bendout]  bug?
[bendin]'s current implementation is closer to the actual MIDI messages being 
transmitted.


 
  From: Alexandre Torres Porres 
 To: "pd-list@lists.iem.at"  
 Sent: Sunday, 4 September 2016, 17:26
 Subject: [PD] bendin bug (?)
   
so, bendout takes from -8192 to 8191, but bendin will receive from 0 to 16383, 
which is inconsistent with the bendin message, can it be considered a bug and 
fixed?
cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


   
 ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Once again, -guiport -nogui

[Giulio Moro via Pd-list]

I am re-upping this as I did not get any response.
 
  From: Giulio Moro 
 To: Pd list  
 Sent: Monday, 22 August 2016, 12:33
 Subject: Once again, -guiport -nogui
   
Hi,I dug as much as I could into past posts on this topic, like these 
https://lists.puredata.info/pipermail/pd-list/2007-08/052611.html
and this https://lists.puredata.info/pipermail/pd-list/2008-05/061978.html
but I yet have to find the answer to:
How do Ia) start the GUI with no DSP ?b) start the DSP with no GUI ?c) have the 
two communicate together nicely?
So far I have only managed (on Mac OS X) to - start the regular Pd- start a 
process with -guiport 5400 which connects to the existing GUI- kill the DSP 
process that came with the GUI, the GUI still runs- at this point, patching in 
the GUI is very slow and blocks are very small and the text is outside the box- 
if I try to create [dac~] or [adc~] I get a "couldn't create"
There must be a better (and working) way of doing this.Once I get it to work on 
one computer, I believe it should just work when using two computers, right?
Thanks,Giulio

   
 ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] Once again, -guiport -nogui

[Giulio Moro via Pd-list]

Hi,I dug as much as I could into past posts on this topic, like these 
https://lists.puredata.info/pipermail/pd-list/2007-08/052611.html
and this https://lists.puredata.info/pipermail/pd-list/2008-05/061978.html
but I yet have to find the answer to:
How do Ia) start the GUI with no DSP ?b) start the DSP with no GUI ?c) have the 
two communicate together nicely?
So far I have only managed (on Mac OS X) to - start the regular Pd- start a 
process with -guiport 5400 which connects to the existing GUI- kill the DSP 
process that came with the GUI, the GUI still runs- at this point, patching in 
the GUI is very slow and blocks are very small and the text is outside the box- 
if I try to create [dac~] or [adc~] I get a "couldn't create"
There must be a better (and working) way of doing this.Once I get it to work on 
one computer, I believe it should just work when using two computers, right?
Thanks,Giulio___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list