[PD] Pd activities/places at the west coast? netpd tour?

2013-09-19 Thread Roman Haefeli
Hi all

I'm traveling with my family at the west coast of North America, between
Vancouver and San Francisco until the end of the year. We're certainly
going to visit at least some of the major cities near the coast line.

We don't have any particular plans or schedules, but I'd enjoy to take
the chance to connect with Pd people in the areas we're going to visit.
If you know of Patching Circles or have an exhibition running or know of
any other Pd related activities, please drop me a line off-list.  

In shameless manner of self-promotion, I'm also looking for places to
present netpd, either by giving workshops or having live jams with
interested people. If you know of suitable locations, please let me
know.

Thanks and take care!

Roman

--
http://www.netpd.org/About
--


 


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


Re: [PD] Sum of delays...

2013-09-19 Thread Frank Barknecht
Hi,

On Thu, Sep 19, 2013 at 02:20:28PM -0300, Mario Mey wrote:
> I think most of s/r and throw/catch are between abstracts. If I want
> to sort that objects (as Theory of Operation says: creating receive~
> after send~)... I don't know how to do it.

To trick Pd into sorting signal objects, that are not directly connected with
some patchcords (like sends), you must put them into subpatches or abstractions
and then connect these. 

For example this here will be unsorted: 


 [sig~ 1] 
 
 [sig~ 2] 
 
 [sig~ 3]

But this will be sorted: 

 [sig~ 1] 
 |
 [sig~ 2] 
 |
 [sig~ 3]

and this will also be sorted:
 
 [pd sig~1-inside] 
 |
 [pd sig~2-inside] 
 |
 [pd sig~3-inside]

where each subpatch has something like this inside: 

 [inlet~] [outlet~] [sig~ 1]

The 3 objects inside the subpatch don't need do be connected at all, only the
subpatches have to be connected to force an order.

In the end, you have now tricked Pd to execute signals in the order 1, 2 and 3,
although they aren't connected to anything. The order, in which these objects
have been created doesn't matter and you should never rely on creation order
anyway.

Instead of subpatches you can use abstraction, but you have to connect these
just as you have connected the subpatches.

Ciao
-- 
 Frank Barknecht _ __footils.org__

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


Re: [PD] Sum of delays...

2013-09-19 Thread Mario Mey
I think most of s/r and throw/catch are between abstracts. If I want to 
sort that objects (as Theory of Operation says: creating receive~ after 
send~)... I don't know how to do it.


Does the "sorting" include creation of abstracts? I mean, should I 
cut-paste from the objects (s/r, throw/catch AND abstracts) at the start 
of the pipeline (mic) to the last (output)? And so inside each abstract? 
I'm confused... and I'll be more if I would have to do it.


Thanks.




 Mensaje original 
Asunto: Sum of delays...
Fecha:  Thu, 19 Sep 2013 13:52:37 -0300
De: Mario Mey 
Para:   pd-list 



I was guessing... if I made a sum of delays using so many send~ / 
receive~ and throw~ / catch~...


For a full use of my patch (mic input -> FX-A -> FX-B -> output), I have 
this structure (inside subpatches and abstracts):


adc~
s~ mic

r~ mic
s~ console-in-a

r~ console-in-a
s~ pre-fx-a

r~ pre-fx-a
throw~ post-fx-a

catch~ post-fx-a
s~ console-out-a

r~ console-out-a
s~ console-in-b

r~ console-in-b
s~ pre-fx-b

r~ pre-fx-b
throw~ post-fx-b

catch~ post-fx-b
s~ console-out-b

r~ console-out-b
s~ out

r~ out
dac~

Does every send~ / receive~ and throw~ / catch~ adds a 1 block delay?

I'm using 48000, so, do I have 1.333ms * 10 = 13ms of delay because of 
using that objects?





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


[PD] Sum of delays...

2013-09-19 Thread Mario Mey
I was guessing... if I made a sum of delays using so many send~ / 
receive~ and throw~ / catch~...


For a full use of my patch (mic input -> FX-A -> FX-B -> output), I have 
this structure (inside subpatches and abstracts):


adc~
s~ mic

r~ mic
s~ console-in-a

r~ console-in-a
s~ pre-fx-a

r~ pre-fx-a
throw~ post-fx-a

catch~ post-fx-a
s~ console-out-a

r~ console-out-a
s~ console-in-b

r~ console-in-b
s~ pre-fx-b

r~ pre-fx-b
throw~ post-fx-b

catch~ post-fx-b
s~ console-out-b

r~ console-out-b
s~ out

r~ out
dac~

Does every send~ / receive~ and throw~ / catch~ adds a 1 block delay?

I'm using 48000, so, do I have 1.333ms * 10 = 13ms of delay because of 
using that objects?



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


Re: [PD] Sum of delays...

2013-09-19 Thread Frank Barknecht
On Thu, Sep 19, 2013 at 01:52:37PM -0300, Mario Mey wrote:
> I was guessing... if I made a sum of delays using so many send~ /
> receive~ and throw~ / catch~...
> 
> For a full use of my patch (mic input -> FX-A -> FX-B -> output), I
> have this structure (inside subpatches and abstracts):
...  
> Does every send~ / receive~ and throw~ / catch~ adds a 1 block delay?

No, not at all. They only need to add a block of delay, if you use a feedback
path, which you are not as far as I see. However you have to force the order of
execution of your non-local signal connections with s~/r~ and throw~/catch~ to 
avoid 
delays that Pd might introduce when doing its own ordering.

Do this by adding some subpatches as described in the help file:
3.audio.examples/G05.execution.order.pd or use direct connections where
possible.

> I'm using 48000, so, do I have 1.333ms * 10 = 13ms of delay because
> of using that objects?

Block delays with non-local connections will only happen if you don't do order
forcing. But if you are careful, you will have zero delay. 

Ciao
-- 
 Frank Barknecht _ __footils.org__

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


Re: [PD] puredata.info strange behaviour using Google.

2013-09-19 Thread IOhannes m zmoelnig
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2013-09-19 17:34, Mario Mey wrote:
> Everytime I visit puredata.info through google, every "d" and "com"
> in the page are highlighted in yellow. If I refresh (F5) the page,
> it is the same. But, if I click in address and press Enter, the
> highlight dissappear. I think it is something in POST...
> 
> If I search "pure data 0.44", then I click in the first link, "d"
> and "44" are highlighted.
> 
> It is so strange... now, I tried again, the same link and only
> "com" are highlighted. Try this link:
> 
> http://www.google.com.ar/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCwQFjAA&url=http%3A%2F%2Fpuredata.info%2Fdocs%2Fmanuals%2Fpd%2Fx2.htm&ei=Qxc7UtbIEIK3iwK1k4C4DQ&usg=AFQjCNG-AyYLgOX6CkJARANJvkgxHzSsdw&sig2=U9wSrxsBPqsW108sJu3KIA
>
> 
> 
> It's about google? puredata.info?

purdata.info highlights search terms.

e.g. http://puredata.info/Members/ktsoukalas/pd-volos/?searchterm=meeting


will have "meeting" highlighted.


i guess that google-redirects somehow contain hidden search terms.

fgamsdr
IOhannes
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iEYEARECAAYFAlI7Hb8ACgkQkX2Xpv6ydvRUMACgwkcNdzYiG94ZYaqNF4gS2Tl1
agQAnRbmFOLGkIVWFumJ8hQ/QwsV1V96
=5WQE
-END PGP SIGNATURE-

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


[PD] puredata.info strange behaviour using Google.

2013-09-19 Thread Mario Mey
Everytime I visit puredata.info through google, every "d" and "com" in 
the page are highlighted in yellow. If I refresh (F5) the page, it is 
the same. But, if I click in address and press Enter, the highlight 
dissappear. I think it is something in POST...


If I search "pure data 0.44", then I click in the first link, "d" and 
"44" are highlighted.


It is so strange... now, I tried again, the same link and only "com" are 
highlighted. Try this link:


http://www.google.com.ar/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCwQFjAA&url=http%3A%2F%2Fpuredata.info%2Fdocs%2Fmanuals%2Fpd%2Fx2.htm&ei=Qxc7UtbIEIK3iwK1k4C4DQ&usg=AFQjCNG-AyYLgOX6CkJARANJvkgxHzSsdw&sig2=U9wSrxsBPqsW108sJu3KIA

It's about google? puredata.info?

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


Re: [PD] prevent opening of patches

2013-09-19 Thread Matthias Kronlachner

One more thing can be annoying on OSX:
If you open a second instance of Pd, the same patch as in the first will 
be opened.


One good thing to do is to create an AppleScript for opening Pd from the 
Terminal:


* Open AppleScript Editor and past the line: (of course adapt Pd-.app)

tell application "Terminal" to do script 
"/Applications/Pd-0.45-2.app/Contents/Resources/bin/pd"


* Export as Application and put wherever you want.. Now you can open 
multiple instances of Pd with that .app, and patches won't be loaded 
automatically.


Actually funny how complicated things get because of "user experience 
optimizations".


Matthias

On 9/18/13 6:22 PM, Peter Venus wrote:

Hello

i assume, you are working on OSX:
got to system preferences,
click on the General Settings tab
un-tick the box "restore windows when quitting and re-opening apps"
cheers,
Peter

Am 18.09.13 17:05, schrieb IOhannes m zmölnig:

On 09/18/13 16:01, Olivier Baudry wrote:

Dear all

Is there any function to prevent the opening of last patch when you
start pd or pd-extended?


how do you trigger that behaviour?
it doesn't do that here.

fgmasdr
IOhannes



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




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



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


Re: [PD] prevent opening of patches

2013-09-19 Thread Marco Donnarumma
> i assume, you are working on OSX:
> got to system preferences,
> click on the General Settings tab
> un-tick the box "restore windows when quitting and re-opening apps"
> cheers,
> Peter
>
>
Yes, it's a new "feature" of Lion OSX 10.7 and 10.8. It is extremely
annoying with Pd, because as soon as Pd try to reopen some already dead
sockets everything crashes without warning or log.

You can lock the pd folder, so to keep the configuration saving system
running for other software. Here's the how-to on puredata.org by Dan Wilcox:

http://puredata.info/docs/tutorials/HowToTurnOffResumeWindowsForPDOnMacOSX107Lion

I don't have Mac, but had to solve this issue all the time in my last
workshop this past months.

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