Re: [PD] does a clear message to delwrite~ work if DSP is switched off?

[Roman Haefeli]

On Mit, 2018-03-07 at 15:13 +1100, Matt Davey wrote:
> does a clear message to delwrite~ work if DSP is switched off?

It does. I tested it by simply trying it out.

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] how to change the cursor icon (tcl)

[Liam Goodacre]

Several months later, and I've worked out an enhancement on Federico's system 
for changing the cursor icon.

The one limitation with the file Federico uploaded was that you had to minimize 
the window (vis 0) after resetting the cursor, or else it would fail to flip 
the icon when you entered edit mode. I've managed to fix this by modifying the 
hexadecimal canvas symbol. [canvas_name] gives you a symbol that looks 
something like ".c" ; if you just remove the " .c " from the end, then you 
can change the cursor and still enjoy normal behavior in edit mode without 
having to minimize the window.

Just posting this for the record, in case it's useful to anybody.

From: Federico Camara Halac 
Sent: 26 September 2017 21:21
To: Liam Goodacre; Pd-List
Subject: Re: [PD] how to change the cursor icon (tcl)

Hi Liam (back to the list now ;)

You can trigger the cursor change from a subpatch or abstraction, it doesn't 
matter, as long as you are in the same pd instance and the canvas_name symbol 
for the target is visible.

I attached a patch where this is working from inside an abstraction with a 
metro (needs hcs).

 I don't know of any other way to change the cursor type other than sysgui and 
configure -cursor. Also I don't know what you mean by pdsend finished. I guess 
in the end this might be system dependent and probably a tcl version thing that 
I simply don't know ;) all my knowledge here comes from hacking through this 
amazing code

either I don't understand your problem or itseems to be working as far as i can 
see.

cheers

fd


On Tue, Sep 26, 2017 at 3:28 PM, Liam Goodacre 
mailto:liamg...@hotmail.com>> wrote:
Yeah those are the kinds of problems that I've been facing. Ultimately, I want 
to trigger the change from a hidden canvas, ie. inside a canvas. I'm also 
finding that it seems to work only if triggered by a "click" (of a bang or 
message box). Trying to automate the process, ie. with a metro, mysteriously 
fails. (I think this is something to do with the "pdsend finished" message I 
mentioned previously).

Is there any way around these problems, or is this a lost cause?

From: Federico Camara Halac mailto:camaraf...@gmail.com>>
Sent: 26 September 2017 19:46
To: Liam Goodacre
Subject: Re: [PD] how to change the cursor icon (tcl)

Hi Liam, using hcs, I imagine you can use something like this, but it doesn't 
seem to work all the time. The canvas needs to be visible. Moving the mouse in 
an out of the canvas triggers the new cursor on mac at least.

[bang(
|
[canvas_name]  (  the target canvas )
|
[$1 configure -cursor hand((or whatever cursor 
name)
|
[sys_gui]

On Tue, Sep 26, 2017 at 1:33 PM, Liam Goodacre 
mailto:liamg...@hotmail.com>> wrote:

I'm looking for a reliable way to change the cursor icon, ie. from an arrow to 
dot or something else.


The [cursor] object in the hcs library does just this, but it gives a nasty tcl 
error when triggered inside an abstraction. I don't imagine that this library 
will be updated any time soon, so I've been looking for alternatives.


There ought to be a raw tcl messages which can be sent to [sys_gui] (also hcs 
library). I've found one which is promising:


set ::cursor_runmode_nothing "left_side"


But I'm running into difficulties with this also, as it seems to expect a 
"pdsend xxx finished" message, where xxx is some hexadecimal that I can't work 
out.


Does anybody know how to make this work?


Liam

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




--
http://fdch.github.io/tv



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

[PD] does a clear message to delwrite~ work if DSP is switched off?

[Matt Davey]

does a clear message to delwrite~ work if DSP is switched off?
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Porting Max MSP externals to Pure Data

[Ed Kelly via Pd-list]

Hey Patrick,
So, I've probably screwed up some stuff here with GSL, but I've been learning a 
hell of a lot with regards to vector operations, and porting the vDSP 
accelerate stuff to GSL. Eventually I suppose it would be good to get rid of 
that, and only use standard libs, except where the FFT stuff is concerned when 
we'll use either d_fft_fftdg.c or d_fft_fftw.c from pd src.
Also, I was reading an article about dereferencing, and I think I might have 
used &x-> where just x-> is needed for gsl_vector_float operations, and I know 
the initialization functions gsl_vector_float_calloc() are wrong sized - I need 
to work out which need to be MAX_ORDER and which to be sized and initialized at 
size = nfft or size = nfft02 (It's 10pm and I'm also trying to master an album!)

Well, it's messy right now. Don't bust a gut on working all of it out, but if 
you can speed me up by spotting a few things it'd be appreciated.
I feel like I've absorbed a couple of megabytes in my head since the weekend.

Cheers,Ed
Enclosed - the original Max code and my incomplete hash of it - but I'm trying 
to port the hardest bit I think...Things will be renamed before a release to 
acknowledge Mark Cartwright, (as in mbc.lpc~ for the original MSP extern) but I 
haven't decided on the namespace options yet.


_-_-_-_-_-_-_-^-_-_-_-_-_-_-_

For Lone Shark releases, Pure Data software and published Research, go to 
http://sharktracks.co.uk  

On Tuesday, 6 March 2018, 19:41:16 GMT, Pagano, Patrick 
 wrote:  
 
 #yiv6390742159 #yiv6390742159 -- P 
{margin-top:0;margin-bottom:0;}#yiv6390742159 
Let me know how i can help ed




pp




Patrick Pagano B.S, M.F.A

Assistant Professor in Residence

Digital Media & Design


Web & Interactive Technologies

UCONN ECE Faculty Coordinator

University of Connecticut, Stamford

(352)-226-2016
From: Pd-list  on behalf of Simon Iten 

Sent: Tuesday, March 6, 2018 2:22:54 PM
To: Ed Kelly
Cc: pd list
Subject: Re: [PD] Porting Max MSP externals to Pure Data cool, thanks!

On 6 Mar 2018, at 17:25, Ed Kelly  wrote:
Encoding and decoding of LPC streams.I know you eagerly anticipate this! I have 
a lot of work to do...Ed


_-_-_-_-_-_-_-^-_-_-_-_-_-_-_

For Lone Shark releases, Pure Data software and publishedResearch, go to 
http://sharktracks.co.uk 

On Sunday, 4 March 2018, 22:11:46 GMT, Simon Iten  wrote:

you are my hero. what will they do exactly? lcp encoding, decoding? lcp-streams 
to audio?
cheers

On 4 Mar 2018, at 15:30, Ed Kelly via Pd-list  wrote:
Hi List,
I'm porting a library of LPC externals from Max/MSP to Pd.I wonder if someone 
could point me towards an example of another MSP external that has successfully 
been ported to Pd - preferably a DSP external that has creation arguments, with 
code for both so I can identify the differences between coding for the two 
platforms.
Cheers,Ed

_-_-_-_-_-_-_-^-_-_-_-_-_-_-_

For Lone Shark releases, Pure Data software and published Research, go 
tohttp://sharktracks.co.uk ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list




  /**
	@file
	mbc.lpc~ - an MSP object shell
	mark cartwright - mcartwri...@gmail.com	

	@ingroup	lpcToolkit	
*/

#include "ext.h"			// standard Max include, always required (except in Jitter)
#include "ext_obex.h"		// required for new style objects
#include "z_dsp.h"			// required for MSP objects
#include 
#include 

#define MAX_ORDER 200
#define NLOG2(x) (ceil(log2(x)))
#define POW2(x) (1 << x);
#define DEFAULT_FS 44100
#define DEFAULT_FRAMERATE 100
#define DEFAULT_V_SIZE 64

// object struct
typedef struct _lpc 
{
	t_pxobject	ob;	// the object itself (t_pxobject in MSP)
	t_float*	l_frame_buff;		//input frame buffer
	t_float*	l_winframe_buff;	//windowed input frame buffer
	t_float*	l_outCoeff_buff;	//coefficient signal
	t_float*	l_outParcor_buff; 	//PARCOR coeffs
	t_float*	l_outError_buff;	//error signal
	t_float*	l_win;//analysis window
	t_float*	l_R;
	double*		l_W;
	double*		l_E;
	double*		l_K;
	double 		l_G;
	double**	l_A;
	double 		l_x1;//last samples of pre-emphasis filter
	float 		l_b1;//pre-emph coefficient
	int 		l_order;			//predictor order
	int 		l_order_max;		//max order according to fs = order * frame_rate
	int 		l_preemph;			//pre-epmhasis filter on/off
	int 		l_frame_rate;		//analysis frame rate
	int 		l_frame_size;		//analysis frame size, where fs = frame_rate * frame_size * 2
	int 		l_hop_size;			//hop_size = frame_size * 2 (b/c of overlap)
	int 		l_inframe_idx;		//current inframe buffer index
	int 		l_outframe_idx;		//current outframe buffer index
	long 		l_v_size;			//vector size
	float 		l_fs;//sampling rate
	int 		l_maxnfft;			//fft length
	int 		l_log2nfft;			//log2(fft length)
	FFTSetup 	l_fftsetup;			//FFTSetup for vDSP

Re: [PD] avoid "properities"/"open" options in abstractions

[Alexandre Torres Porres]

2018-03-06 16:02 GMT-03:00 Alexandre Torres Porres :

> I have a couple of such examples in my library.
>

Actually I have much more, dozens of it, as I don't think any non graphical
abstraction of mine needs properties! I was just thinking and meant about
the graphical ones, which even so don't always need properties... but I
forgot to mention about the non graphical ones.

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

Re: [PD] Porting Max MSP externals to Pure Data

[Pagano, Patrick]

Let me know how i can help ed


pp


Patrick Pagano B.S, M.F.A

Assistant Professor in Residence

Digital Media & Design

Web & Interactive Technologies

UCONN ECE Faculty Coordinator

University of Connecticut, Stamford

(352)-226-2016


From: Pd-list  on behalf of Simon Iten 

Sent: Tuesday, March 6, 2018 2:22:54 PM
To: Ed Kelly
Cc: pd list
Subject: Re: [PD] Porting Max MSP externals to Pure Data

cool, thanks!
On 6 Mar 2018, at 17:25, Ed Kelly 
mailto:morph_2...@yahoo.co.uk>> wrote:

Encoding and decoding of LPC streams.
I know you eagerly anticipate this! I have a lot of work to do...
Ed


_-_-_-_-_-_-_-^-_-_-_-_-_-_-_

For Lone Shark releases, Pure Data software and published Research, go to 
http://sharktracks.co.uk


On Sunday, 4 March 2018, 22:11:46 GMT, Simon Iten 
mailto:itensi...@gmail.com>> wrote:


you are my hero. what will they do exactly? lcp encoding, decoding? lcp-streams 
to audio?

cheers

On 4 Mar 2018, at 15:30, Ed Kelly via Pd-list 
mailto:pd-list@lists.iem.at>> wrote:

Hi List,

I'm porting a library of LPC externals from Max/MSP to Pd.
I wonder if someone could point me towards an example of another MSP external 
that has successfully been ported to Pd - preferably a DSP external that has 
creation arguments, with code for both so I can identify the differences 
between coding for the two platforms.
Cheers,
Ed

_-_-_-_-_-_-_-^-_-_-_-_-_-_-_

For Lone Shark releases, Pure Data software and published Research, go to 
http://sharktracks.co.uk
___
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] Porting Max MSP externals to Pure Data

[Simon Iten]

cool, thanks!
> On 6 Mar 2018, at 17:25, Ed Kelly  wrote:
> 
> Encoding and decoding of LPC streams.
> I know you eagerly anticipate this! I have a lot of work to do...
> Ed
> 
> 
> _-_-_-_-_-_-_-^-_-_-_-_-_-_-_
> 
> For Lone Shark releases, Pure Data software and published Research, go to 
> http://sharktracks.co.uk  
> 
> 
> On Sunday, 4 March 2018, 22:11:46 GMT, Simon Iten  wrote:
> 
> 
> you are my hero. what will they do exactly? lcp encoding, decoding? 
> lcp-streams to audio?
> 
> cheers
> 
>> On 4 Mar 2018, at 15:30, Ed Kelly via Pd-list > > wrote:
>> 
>> Hi List,
>> 
>> I'm porting a library of LPC externals from Max/MSP to Pd.
>> I wonder if someone could point me towards an example of another MSP 
>> external that has successfully been ported to Pd - preferably a DSP external 
>> that has creation arguments, with code for both so I can identify the 
>> differences between coding for the two platforms.
>> Cheers,
>> Ed
>> 
>> _-_-_-_-_-_-_-^-_-_-_-_-_-_-_
>> 
>> For Lone Shark releases, Pure Data software and published Research, go to 
>> http://sharktracks.co.uk  
>> ___
>> 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] avoid "properities"/"open" options in abstractions

[Alexandre Torres Porres]

yes, I know, and it's great and awesome, but there might also be the case
where you don't really want to have any properties at all, cause it's just
a simple abstraction. I have a couple of such examples in my library. And I
think it would be worse to come up with dummy properties just for the sake
of having properties, just because you're not allowed to not have
properties. In other words, it can also be limiting to force it to have
properties.

cheers

2018-03-06 15:52 GMT-03:00 IOhannes m zmölnig :

> On 03/06/2018 07:23 PM, Alexandre Torres Porres wrote:
> > Now, in my defense, I can say there could be not so pointless features
> > here. Like, I have a nice GUI abstraction, and people may think it's an
> > external and that they can change its properties, but it's not, so it'd
> be
> > nice to suppress the properties option, I think. And I don't think it's
> > nice to have a useless and pointless canvas properties for a GUI
> > abstraction. Now, if this were an external, it would just not show any
> > properties, because there isn't one, but when it comes to abstractions,
> we
> > do not have a choice... Moreover, it wouldn't add any dependency, as this
> > would be for my external library, and the abstraction already has
> > dependencies to other externals in the library.
>
>
> you know, with [propertybang] your GUI abstraction would (well: could)
> have *real* properties. not just the generic ones every abstraction has,
> but properties like GUI externals.
> which i think is rather more interesting than having no properties menu.
>
> fgadsmr
> 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] avoid "properities"/"open" options in abstractions

[IOhannes m zmölnig]

On 03/06/2018 07:23 PM, Alexandre Torres Porres wrote:
> Now, in my defense, I can say there could be not so pointless features
> here. Like, I have a nice GUI abstraction, and people may think it's an
> external and that they can change its properties, but it's not, so it'd be
> nice to suppress the properties option, I think. And I don't think it's
> nice to have a useless and pointless canvas properties for a GUI
> abstraction. Now, if this were an external, it would just not show any
> properties, because there isn't one, but when it comes to abstractions, we
> do not have a choice... Moreover, it wouldn't add any dependency, as this
> would be for my external library, and the abstraction already has
> dependencies to other externals in the library.


you know, with [propertybang] your GUI abstraction would (well: could)
have *real* properties. not just the generic ones every abstraction has,
but properties like GUI externals.
which i think is rather more interesting than having no properties menu.

fgadsmr
IOhannes



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

Re: [PD] avoid "properities"/"open" options in abstractions

[Alexandre Torres Porres]

Yeah, like I said, I can see the criticism, but I was hoping to avoid the
discussion and just stick to the technical issue if it is possible or not.

Now, in my defense, I can say there could be not so pointless features
here. Like, I have a nice GUI abstraction, and people may think it's an
external and that they can change its properties, but it's not, so it'd be
nice to suppress the properties option, I think. And I don't think it's
nice to have a useless and pointless canvas properties for a GUI
abstraction. Now, if this were an external, it would just not show any
properties, because there isn't one, but when it comes to abstractions, we
do not have a choice... Moreover, it wouldn't add any dependency, as this
would be for my external library, and the abstraction already has
dependencies to other externals in the library.

Now, regarding the clicking thing, I thought one could use it to not only
prevent from opening, but also make the object react and do something when
clicked. Again, this is something we can do with externals, as you can
program an object to react to clicking. In cyclone we have [loadmess] that
outputs a loaded message when clicked. In else I have [loadbanger] that can
send bangs when clicked.

People would still be able to open and check the abstraction. The
documentation would still mention the object is an abstraction and that you
can check it out.

Now, this [protect_against_open] object is indeed funny. But it doesn't
interfere with the right click options, and is just kinda hardcore, as
it'll just close the patch you're working on if you include it, and it also
seems it won't ever let you open a subpatch again :) and I can't help but
think about this https://www.youtube.com/watch?v=aqAUmgE3WyM haha

Anyway, I'm now throwing a few balls in the air here, like how to prevent
from opening when clicking, how to make it respond to clicking, and how to
change the right clicking options and suppress some of them (specially
properties).

So, one thing at a time, and let me focus on technical issue about being
possible or not to suppress the properties option, for starters. So, what
do you say?

I have my doubts it's even possible, and I figure if there is a way, it's
probably not too trivial.

thanks


2018-03-06 14:41 GMT-03:00 Dan Wilcox :

> It also goes against one the best things about Pd: peeking under the hood
> for abstractions. Are adding dependencies/workarounds really worth the time
> for something that is at most a "nice to have"? (I ask myself this more and
> more the older I get...)
>
> On Mar 6, 2018, at 6:31 PM, pd-list-requ...@lists.iem.at wrote:
>
> but if you just want to prevent users from opening up objects in your
> publicly facing installation
>
>
> Nope, the idea is just try and make an abstraction behave like a compiled
> external. I know some people might think that's crazy, ludicrous,
> pointless, stupid, counterproductive, shameful and just bad... but... I
> liked the idea :)
>
>
> 
> 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

Re: [PD] avoid "properities"/"open" options in abstractions

[Dan Wilcox]

It also goes against one the best things about Pd: peeking under the hood for 
abstractions. Are adding dependencies/workarounds really worth the time for 
something that is at most a "nice to have"? (I ask myself this more and more 
the older I get...)

> On Mar 6, 2018, at 6:31 PM, pd-list-requ...@lists.iem.at wrote:
> 
>> but if you just want to prevent users from opening up objects in your
>> publicly facing installation
> 
> Nope, the idea is just try and make an abstraction behave like a compiled
> external. I know some people might think that's crazy, ludicrous,
> pointless, stupid, counterproductive, shameful and just bad... but... I
> liked the idea :)


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

Re: [PD] avoid "properities"/"open" options in abstractions

[IOhannes m zmölnig]

On 03/06/2018 06:29 PM, Alexandre Torres Porres wrote:
> Nope, the idea is just try and make an abstraction behave like a compiled
> external. I know some people might think that's crazy, ludicrous,
> pointless, stupid, counterproductive, shameful and just bad... but... I
> liked the idea :)

it *is* pointless.

apart from that, the iemlib (iemlib2 to be precise) has an (equally
pointless) object called [protect_against_open] which will just close
the canvas whenever you try to open it.

gfrdsa
IOhannes



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

Re: [PD] readsf re-blocked up-sampled

[IOhannes m zmölnig]

On 03/06/2018 03:25 PM, Marco Matteo Markidis wrote:
> I think the problem in reading soundfile from hard disk is to access to it,

obviously.

> so reducing the accesses to hard disk can be a good practice to reduce
> audio interruption.

not necessarily.
there is an operating system between Pd and the harddisk that does all
kinds of caching and what not.
also, if you have a spinning harddrive (as opposed to SSD) you will have
much better performance if the disk keeps spinning (e.g. by polling it
often).

> 
> the idea to write in a table and then read it outside the up-sampled canvas
> sounds great, however it is not clear how to read chunks without every time
> close the file descriptor. could be an idea to add a method for read chunks
> without close the fd? or there is an alternative way without write code?

afaict, you misunderstood the idea.

actually [readsf~] is quite good when it comes to reading soundfiles
without blocking. the soundfile reading happends in a separate thread
(so the main/audio thread will not be blocked) and you can specify a
buffer time to give it enough time to seek the file.

but if you have a high bandwidth signal (e.g. a heavy multitrack
recording) and the disk is just too slow to serve that data, then you
can open and close file descriptors and juggle with blocks-to-read as
you will, without being able to solve the problem.

so if tweaking the buffer size doesn't give you click-free play back, i
doubt whether *anything* will help, short of getting a faster harddisk
(RAMdisk, SSD, nvram).

gfdstr
IOhannes



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

Re: [PD] How can a signal inlet of an object know if it's receiving a signal

[Alex]

I put up a related 'enhancement' PR a bit ago for [inlet~]
https://github.com/pure-data/pure-data/issues/259

I dug into the ugen graph code a bit and got lost trying to implement it
myself..

On Tue, Mar 6, 2018 at 9:22 AM, Miller Puckette  wrote:

> This too is on my (almost infinitely long) dolist... to somehow extend the
> "dsp" message to allow objects to find out whether there are signals
> connected
> or not (and perhaps also to be able to deal with unequal-sized arrays
> somehow).
>
> Main reason I think this is needed is so that objects like "vcf~" can take
> audio signals to change "q" without always assuming they're audio (which
> would cause more overhead).
>
> cheers
> Miller
>
> On Tue, Mar 06, 2018 at 05:12:37PM +0100, Christof Ressi wrote:
> > the object doesn't know but the ugen graph algorithm does. if it sees
> that a signal inlet is not connected it creates a new signal and adds a
> scalar copy routine to the DSP chain.
> > the scalar value is stored in the inletunion in struct _inlet (m_obj.c)
> and it's updated whenever you send a float message to the inlet.
> > the first inlet is somewhat special in that you can use the
> CLASS_MAINSIGNALIN macro to store the scalar value directly in the class
> (usually named x_f).
> >
> > have a look at ugen_doit in d_ugen.c:
> >
> > if (!uin->i_nconnect)
> > {
> > t_float *scalar;
> > s3 = signal_new(dc->dc_calcsize, dc->dc_srate);
> > /* post("%s: unconnected signal inlet set to zero",
> >class_getname(u->u_obj->ob_pd)); */
> > if ((scalar = obj_findsignalscalar(u->u_obj, i)))
> > dsp_add_scalarcopy(scalar, s3->s_vec, s3->s_n);
> > else
> > dsp_add_zero(s3->s_vec, s3->s_n);
> > uin->i_signal = s3;
> > s3->s_refcount = 1;
> > }
> >
> >
> > > Gesendet: Dienstag, 06. März 2018 um 16:08 Uhr
> > > Von: Alexandros 
> > > An: Pd-List 
> > > Betreff: [PD] How can a signal inlet of an object know if it's
> receiving a signal
> > >
> > > [phasor~] ([osc~], and probably other objects too) seems to be aware of
> > > signals being connected to its left-most inlet. Providing an argument
> to
> > > [phasor~], if there's no signal coming in its inlet, it will use its
> > > argument for the frequency. As soon as a signal is connected, it will
> > > use that signal for its frequency. As soon as this signal gets
> > > disconnected (even if the signal is 0), [phasor~] will go back to using
> > > its argument for its frequency.
> > >
> > > Reading [phasor~]'s code in d_osc.c, I can't understand how this is
> > > achieved. I thought of looking into canvasconnections.c from the
> iemguts
> > > library, but it's a bit too complicated for me. Still, there's this
> > > comment in that file:
> > >
> > > /* as Pd does not have any information about connections to inlets,
> > >  * we have to find out ourselves
> > >  * this is done by traversing all objects in the canvas and try
> > >  * to find out, whether they are connected to us!
> > >  */
> > >
> > > Does this have to do with control inlets only? How can [phasor~] know
> if
> > > it's receiving a singal in its frequency inlet?
> > >
> > >
> > >
> > > ___
> > > 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] avoid "properities"/"open" options in abstractions

[Alexandre Torres Porres]

2018-03-06 6:34 GMT-03:00 IOhannes m zmoelnig :

> On 2018-03-06 00:53, Alexandre Torres Porres wrote:
>
> the right-click menu can be changed


Ok, but how about being suppressed? Can it be?


> (e.g. see the iemguts' [propertybang] object, which changes the effect of
> the "Properties" item
> in the menu, and requires some extra code to hide this for canvases that
> don't have a a [propertybang] object).
>

Awesome!!! And I guess one can use this and then don't do anything with the
bang output, this would effectively avoid the canvas properties from
showing up, but my ideal concept would be completely hide and avoid the
"properties" option to be highlighted and show up.

I wonder if it is possible at all... [propertybang] shows us how to change
and mess with it, but how would you actually hide the properties?


> but if you just want to prevent users from opening up objects in your
> publicly facing installation


Nope, the idea is just try and make an abstraction behave like a compiled
external. I know some people might think that's crazy, ludicrous,
pointless, stupid, counterproductive, shameful and just bad... but... I
liked the idea :)

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

Re: [PD] How can a signal inlet of an object know if it's receiving a signal

[Miller Puckette]

This too is on my (almost infinitely long) dolist... to somehow extend the
"dsp" message to allow objects to find out whether there are signals connected
or not (and perhaps also to be able to deal with unequal-sized arrays somehow).

Main reason I think this is needed is so that objects like "vcf~" can take
audio signals to change "q" without always assuming they're audio (which
would cause more overhead).

cheers
Miller

On Tue, Mar 06, 2018 at 05:12:37PM +0100, Christof Ressi wrote:
> the object doesn't know but the ugen graph algorithm does. if it sees that a 
> signal inlet is not connected it creates a new signal and adds a scalar copy 
> routine to the DSP chain. 
> the scalar value is stored in the inletunion in struct _inlet (m_obj.c) and 
> it's updated whenever you send a float message to the inlet. 
> the first inlet is somewhat special in that you can use the 
> CLASS_MAINSIGNALIN macro to store the scalar value directly in the class 
> (usually named x_f).
> 
> have a look at ugen_doit in d_ugen.c:
> 
> if (!uin->i_nconnect)
> {
> t_float *scalar;
> s3 = signal_new(dc->dc_calcsize, dc->dc_srate);
> /* post("%s: unconnected signal inlet set to zero",
>class_getname(u->u_obj->ob_pd)); */
> if ((scalar = obj_findsignalscalar(u->u_obj, i)))
> dsp_add_scalarcopy(scalar, s3->s_vec, s3->s_n);
> else
> dsp_add_zero(s3->s_vec, s3->s_n);
> uin->i_signal = s3;
> s3->s_refcount = 1;
> }
> 
> 
> > Gesendet: Dienstag, 06. März 2018 um 16:08 Uhr
> > Von: Alexandros 
> > An: Pd-List 
> > Betreff: [PD] How can a signal inlet of an object know if it's receiving a 
> > signal
> >
> > [phasor~] ([osc~], and probably other objects too) seems to be aware of
> > signals being connected to its left-most inlet. Providing an argument to
> > [phasor~], if there's no signal coming in its inlet, it will use its
> > argument for the frequency. As soon as a signal is connected, it will
> > use that signal for its frequency. As soon as this signal gets
> > disconnected (even if the signal is 0), [phasor~] will go back to using
> > its argument for its frequency.
> > 
> > Reading [phasor~]'s code in d_osc.c, I can't understand how this is
> > achieved. I thought of looking into canvasconnections.c from the iemguts
> > library, but it's a bit too complicated for me. Still, there's this
> > comment in that file:
> > 
> > /* as Pd does not have any information about connections to inlets,
> >  * we have to find out ourselves
> >  * this is done by traversing all objects in the canvas and try
> >  * to find out, whether they are connected to us!
> >  */
> > 
> > Does this have to do with control inlets only? How can [phasor~] know if
> > it's receiving a singal in its frequency inlet?
> > 
> > 
> > 
> > ___
> > 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] clone object - dynamically change number of instances?

[Miller Puckette]

This is indeed on my dolist... at least to receive a message to change the
number of voices, perhaps not to be able to do so automatically (that seems
to raise problems I donlt know how to solve :)

M

On Tue, Mar 06, 2018 at 11:04:15AM +0100, hans w. koch wrote:
> someone with a better memory…or searching skills…
> :-)
> lets hope it gets upped on the to do list this way.
> 
> 
> 
> > Am 06.03.2018 um 10:38 schrieb IOhannes m zmoelnig :
> > 
> > On 2018-03-06 00:58, hans w. koch wrote:
> >> is there any known way to dynamically change the number of instances 
> >> associated with a clone object, e.g. via message?
> >> i know, the dsp graph would need to be rebulit, but for a project i am 
> >> contemplating that would be less of a concern.
> >> 
> >> if not, can i suggest this for consideration as a feature request?
> > 
> > https://lists.puredata.info/pipermail/pd-dev/2018-01/021422.html
> > 
> > fgmasdr
> > 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

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

Re: [PD] Porting Max MSP externals to Pure Data

[Ed Kelly via Pd-list]

Encoding and decoding of LPC streams.I know you eagerly anticipate this! I have 
a lot of work to do...Ed


_-_-_-_-_-_-_-^-_-_-_-_-_-_-_

For Lone Shark releases, Pure Data software and published Research, go to 
http://sharktracks.co.uk  

On Sunday, 4 March 2018, 22:11:46 GMT, Simon Iten  
wrote:  
 
 you are my hero. what will they do exactly? lcp encoding, decoding? 
lcp-streams to audio?
cheers

On 4 Mar 2018, at 15:30, Ed Kelly via Pd-list  wrote:
Hi List,
I'm porting a library of LPC externals from Max/MSP to Pd.I wonder if someone 
could point me towards an example of another MSP external that has successfully 
been ported to Pd - preferably a DSP external that has creation arguments, with 
code for both so I can identify the differences between coding for the two 
platforms.
Cheers,Ed

_-_-_-_-_-_-_-^-_-_-_-_-_-_-_

For Lone Shark releases, Pure Data software and published Research, go to 
http://sharktracks.co.uk ___
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] How can a signal inlet of an object know if it's receiving a signal

[Christof Ressi]

the object doesn't know but the ugen graph algorithm does. if it sees that a 
signal inlet is not connected it creates a new signal and adds a scalar copy 
routine to the DSP chain. 
the scalar value is stored in the inletunion in struct _inlet (m_obj.c) and 
it's updated whenever you send a float message to the inlet. 
the first inlet is somewhat special in that you can use the CLASS_MAINSIGNALIN 
macro to store the scalar value directly in the class (usually named x_f).

have a look at ugen_doit in d_ugen.c:

if (!uin->i_nconnect)
{
t_float *scalar;
s3 = signal_new(dc->dc_calcsize, dc->dc_srate);
/* post("%s: unconnected signal inlet set to zero",
   class_getname(u->u_obj->ob_pd)); */
if ((scalar = obj_findsignalscalar(u->u_obj, i)))
dsp_add_scalarcopy(scalar, s3->s_vec, s3->s_n);
else
dsp_add_zero(s3->s_vec, s3->s_n);
uin->i_signal = s3;
s3->s_refcount = 1;
}


> Gesendet: Dienstag, 06. März 2018 um 16:08 Uhr
> Von: Alexandros 
> An: Pd-List 
> Betreff: [PD] How can a signal inlet of an object know if it's receiving a 
> signal
>
> [phasor~] ([osc~], and probably other objects too) seems to be aware of
> signals being connected to its left-most inlet. Providing an argument to
> [phasor~], if there's no signal coming in its inlet, it will use its
> argument for the frequency. As soon as a signal is connected, it will
> use that signal for its frequency. As soon as this signal gets
> disconnected (even if the signal is 0), [phasor~] will go back to using
> its argument for its frequency.
> 
> Reading [phasor~]'s code in d_osc.c, I can't understand how this is
> achieved. I thought of looking into canvasconnections.c from the iemguts
> library, but it's a bit too complicated for me. Still, there's this
> comment in that file:
> 
> /* as Pd does not have any information about connections to inlets,
>  * we have to find out ourselves
>  * this is done by traversing all objects in the canvas and try
>  * to find out, whether they are connected to us!
>  */
> 
> Does this have to do with control inlets only? How can [phasor~] know if
> it's receiving a singal in its frequency inlet?
> 
> 
> 
> ___
> 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] How can a signal inlet of an object know if it's receiving a signal

[Alexandros]

[phasor~] ([osc~], and probably other objects too) seems to be aware of
signals being connected to its left-most inlet. Providing an argument to
[phasor~], if there's no signal coming in its inlet, it will use its
argument for the frequency. As soon as a signal is connected, it will
use that signal for its frequency. As soon as this signal gets
disconnected (even if the signal is 0), [phasor~] will go back to using
its argument for its frequency.

Reading [phasor~]'s code in d_osc.c, I can't understand how this is
achieved. I thought of looking into canvasconnections.c from the iemguts
library, but it's a bit too complicated for me. Still, there's this
comment in that file:

/* as Pd does not have any information about connections to inlets,
 * we have to find out ourselves
 * this is done by traversing all objects in the canvas and try
 * to find out, whether they are connected to us!
 */

Does this have to do with control inlets only? How can [phasor~] know if
it's receiving a singal in its frequency inlet?



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

Re: [PD] readsf re-blocked up-sampled

[Marco Matteo Markidis]

I think the problem in reading soundfile from hard disk is to access to it,
so reducing the accesses to hard disk can be a good practice to reduce
audio interruption.

the idea to write in a table and then read it outside the up-sampled canvas
sounds great, however it is not clear how to read chunks without every time
close the file descriptor. could be an idea to add a method for read chunks
without close the fd? or there is an alternative way without write code?

best,
marco matteo markidis

2018-03-05 13:00 GMT+01:00 IOhannes m zmoelnig :

> On 2018-03-05 12:01, Marco Matteo Markidis wrote:
> > In my head the point is: is it usefull to use a [readsf~] in a up-sampled
> > subpatch to avoid audio dropout? My idea was to up-sampling and
> re-blocking
> > a subpatch with [readsf~] and pass signal using [outlet~] to the main
> > canvas. In this way [readsf~] has a larger blocksize read and it is
> called
> > more often than the main canvas.
> i don't think i can follow the logic: how would having a larger
> blocksize that is called more often reduce audio dropouts?
>
>
> if you care about reading larger chunks of the audio-file per block, you
> can just re-block the subpatch (without upsampling), and then the signal
> sent through [outlet~] will have the correct sample rate (and length,
> and pitch).
>
> if you want to replace [soundfiler] with something that takes a little
> longer to read a soundfile into a table and therefore avoids dropouts
> (because it doesn't have to do all the work in a single DSP tick), you
> can use an upsampled (and probably reblocked) subpatch to read the
> soundfile with [readsf~], and write it into the table *inside* the
> re-blocked canvas.
> then access the data from outside (without re-sampling) and the data
> will be correct.
>
> fgmasdr
> IOhannes
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>


-- 
Ho cambiato l'indirizzo email in mm.marki...@autistici.org . Se non è un
problema, scrivimi a questo nuovo indirizzo email.

I changed my email address in mm.marki...@autistici.org . If it is ok for
you, please write me to this new email address.
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] clone object - dynamically change number of instances?

[hans w. koch]

someone with a better memory…or searching skills…
:-)
lets hope it gets upped on the to do list this way.



> Am 06.03.2018 um 10:38 schrieb IOhannes m zmoelnig :
> 
> On 2018-03-06 00:58, hans w. koch wrote:
>> is there any known way to dynamically change the number of instances 
>> associated with a clone object, e.g. via message?
>> i know, the dsp graph would need to be rebulit, but for a project i am 
>> contemplating that would be less of a concern.
>> 
>> if not, can i suggest this for consideration as a feature request?
> 
> https://lists.puredata.info/pipermail/pd-dev/2018-01/021422.html
> 
> fgmasdr
> 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] clone object - dynamically change number of instances?

[IOhannes m zmoelnig]

On 2018-03-06 00:58, hans w. koch wrote:
> is there any known way to dynamically change the number of instances 
> associated with a clone object, e.g. via message?
> i know, the dsp graph would need to be rebulit, but for a project i am 
> contemplating that would be less of a concern.
> 
> if not, can i suggest this for consideration as a feature request?

https://lists.puredata.info/pipermail/pd-dev/2018-01/021422.html

fgmasdr
IOhannes



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

Re: [PD] avoid "properities"/"open" options in abstractions

[IOhannes m zmoelnig]

On 2018-03-06 00:53, Alexandre Torres Porres wrote:
> Hi, I'm looking for a way to avoid "properties" from popping up as an
> option when right clicking in an abstraction.
> 
> This is not really "important", basically only merely aesthetical, as I
> want to make abstractions look more closely as compiled objects... but
> anyway, please don't judge :)
> 
> So, is there a way to do it? Like an external out there? If not, I guess I
> need to figure out how to make my own...
> 
> Moreover, I'm also after a way to avoid clicking on an abstraction and
> opening it, or also even preventing the "open" option from the right click
> menu as well.

the right-click menu can be changed, but this would apply to *all*
abstractions, not just specific ones (e.g. see the iemguts'
[propertybang] object, which changes the effect of the "Properties" item
in the menu, and requires some extra code to hide this for canvases that
don't have a a [propertybang] object).

but if you just want to prevent users from opening up objects in your
publicly facing installation, i'd do:
- make all public objects GOP (even if they are not effectively showing
anything, this will prevent the abstraction from being opened by "just
clicking")
- use the kiosk-plugin to disable the right-click menu completely
(HidePopup True), so the abstractions cannot be opened via the
context-menu either.

fgmasdr
IOhannes



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

Re: [PD] clone object - dynamically change number of instances?

[Thomas Grill]

Hi all,
if it's not for conceptual reasons or for a very small memory footprint, a 
possible take would be to switch off DSP processing for superfluous voices 
using a switch~ object within the loaded abstraction.
best, Thomas

> Am 06.03.2018 um 09:59 schrieb oliver :
> 
> hans w. koch wrote:
>> hello list,
>> hello miller,
>> 
>> is there any known way to dynamically change the number of instances 
>> associated with a clone object, e.g. via message?
>> i know, the dsp graph would need to be rebulit, but for a project i am 
>> contemplating that would be less of a concern.
> 
> hi, hans !
> 
> you are aware of the "messages to PD" examples ?
> 
> afaict they are not mentioned in the latest official PD release, but i 
> attached one exmaple from PD-extended, that's still valid and documenting 
> this feature. this way you can easily change the instances of a clone object, 
> simply by deleting it and creating a new one with the right arguments.
> 
> if you put your clone object as a single item into a subpatch, it's just a 
> "clear" message and a "obj ... " message to the subpatch.
> 
> coming from MAX/MSP (where this object is called [poly~]), my experience is 
> that assigning a new number of voices via a message does pretty much the same 
> thing: it clears all former instances and reloads the new instances, all 
> loadbang messages sent anew, no values are kept.
> 
> so i guess (while i too would appreciate a "voices" message for [clone]) in 
> the end the result would probably be pretty much the same.
> 
> but mind you, this is no in-depth knowledge, just personal experience
> 
> best
> 
> oliver
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] clone object - dynamically change number of instances?

[oliver]

hans w. koch wrote:

hello list,
hello miller,

is there any known way to dynamically change the number of instances associated 
with a clone object, e.g. via message?
i know, the dsp graph would need to be rebulit, but for a project i am 
contemplating that would be less of a concern.


hi, hans !

you are aware of the "messages to PD" examples ?

afaict they are not mentioned in the latest official PD release, but i 
attached one exmaple from PD-extended, that's still valid and 
documenting this feature. this way you can easily change the instances 
of a clone object, simply by deleting it and creating a new one with the 
right arguments.


if you put your clone object as a single item into a subpatch, it's just 
a "clear" message and a "obj ... " message to the subpatch.


coming from MAX/MSP (where this object is called [poly~]), my experience 
is that assigning a new number of voices via a message does pretty much 
the same thing: it clears all former instances and reloads the new 
instances, all loadbang messages sent anew, no values are kept.


so i guess (while i too would appreciate a "voices" message for [clone]) 
in the end the result would probably be pretty much the same.


but mind you, this is no in-depth knowledge, just personal experience

best

oliver

#N canvas 123 120 1246 795 12;
#X msg 40 732 restore;
#X text 23 29 objects;
#X text 511 33 GUI stuff;
#X msg 515 56 menusave;
#X msg 515 80 menusaveas;
#X msg 515 104 menuclose;
#X msg 515 129 saveto;
#X msg 515 216 cut;
#X msg 515 242 copy;
#X msg 515 290 duplicate;
#X msg 515 153 tidy;
#X msg 515 177 texteditor;
#X msg 515 490 editmode \$1;
#X msg 515 521 loadbang;
#X msg 515 348 menufont;
#X msg 515 432 findagain;
#X msg 515 456 findparent;
#X text 579 130 ?;
#X msg 515 266 paste;
#X msg 515 314 selectall;
#X text 22 470 reset the patch;
#X msg 40 492 clear;
#N canvas 20 500 500 200 subpatch 0;
#X coords 0 200 1 199 50 50 0;
#X restore 513 707 pd subpatch;
#X obj 40 762 s pd-subpatch;
#X obj 515 664 s pd-subpatch;
#X msg 40 236 connect 0 0 1 0;
#X msg 40 575 read textfile.txt;
#X msg 40 599 write textfile.txt;
#X msg 515 558 vis \$1;
#X obj 631 619 loadbang;
#X msg 40 705 donecanvasdialog 1 -1 1 0 -1 1 1 50 50 100 100;
#X text 22 685 this controls graph-on-parent;
#X msg 40 260 disconnect 0 0 1 0;
#X text 178 235 obj# outlet# obj# inlet#;
#X text 117 733 ?;
#X msg 40 173 graph mygraph;
#X obj 173 201 s pd-mygraph;
#X msg 173 173 pop \, array array1 100 float 2;
#X msg 40 49 obj 350 10 r test;
#X msg 40 73 msg 350 40 bang;
#X msg 40 97 floatatom 350 70;
#X msg 40 121 symbolatom 350 100 symbol;
#X msg 40 145 text 350 130 comment;
#N canvas 166 389 487 212 ds 0;
#X obj 38 39 filledcurve 990 0 1 0 0 50 0 50 50 0 50;
#X obj 38 66 drawcurve 0 1 15 15 20 15 20 20 15 20 15 15;
#X obj 38 93 drawcurve 0 1 30 15 35 15 35 20 30 20 30 15;
#X obj 38 120 filledcurve 999 0 1 10 25 25 45 40 25 25 35 10 25;
#X obj 20 12 struct ds float x float y symbol sym;
#X obj 38 147 drawsymbol sym 55 25 0;
#X restore 318 623 pd ds;
#X msg 40 433 motion 200 200 0;
#X msg 40 314 editmode 1;
#X msg 40 385 key 1 8 0;
#X msg 40 337 mouse 340 135 1 0;
#X msg 40 361 mouseup 355 145 0;
#X msg 40 409 click 355 145 0 1 0;
#X text 128 385 (8 = backspace);
#X text 207 409 ?;
#X text 181 434 ?;
#X text 578 558 ( 0 or 1 );
#X text 622 490 ( 0 or 1 );
#X text 23 211 connections;
#N canvas 523 391 265 191 ds2 0;
#N canvas 50 470 557 157 template-toplevel 0;
#X obj 21 102 plot bazoo 700 3 10 20 20;
#X obj 21 68 drawpolygon q 4 0 0 20 z z -5 10 20;
#X obj 21 21 struct template-toplevel float x float y float z float
q array bazoo template-element;
#X restore 11 11 pd template-toplevel;
#N canvas 199 231 600 239 template-element 0;
#X obj 58 83 drawpolygon 10 2 5 0 0 -5 -5 0 0 5 5 0;
#X obj 59 48 struct template-element float x float y float w;
#X restore 11 34 pd template-element;
#X restore 318 587 pd ds2;
#X msg 40 623 scalar ds 225 225 -hi_there!;
#X text 22 551 reading/writing/creating data structures;
#X text 630 408 ( 0 or 1 );
#X text 603 105 Warning !!!;
#N canvas 458 158 549 396 META 0;
#X text 12 5 GENRE tutorial;
#X text 12 65 DESCRIPTION a (hopefully) comprehensive list of all internal
messages that can be sent to a canvas;
#X text 12 95 HELP_PATCH_AUTHORS Damien Henry. "pd meta" information
added by Jonathan Wilkes for Pd version 0.42.;
#X text 12 25 KEYWORDS control canvas_op nonlocal dynamic_patching
;
#X text 12 45 LICENSE public domain;
#X restore 611 707 pd META;
#X text 299 5 MESSAGES TO PD:;
#X obj 496 561 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0
1;
#X obj 495 494 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0
1;
#X obj 494 411 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0
1;
#X msg 515 408 find route \$1;
#X msg 631 644 vis 0 \, clear;
#X text 49 280 events (only work when editmode = 1 \, vis = 1) !;
#X msg 515 372 font \$1 100 100;
#X msg 659 352 12;
#X msg 686 352 10;
#X text 810 19 This will create a sub patch in this w