[PD] Horizontal Connections (Was: Re: style guide idea: [send

2009-03-21 Thread Matt Barber
> Here's my proposal: horizontal connections should only be used when the upper 
> object has only one outlet, and the lower object has only one inlet.  
> Otherwise there will be always be ambiguity.
>
> With your example of all outlets pointing to the same inlet, there is still 
> ambiguity as to whether or not all the outlets are actually connected.  
> That's fine if your patching style is to connect them first, and only line 
> them up after.  But if someone is debugs a patch they made that includes your 
> abstraction, they would have to click and move objects to be certain all the 
> objects are actually connected.


There is one way to be a little less conservative, but it requires a
usage agreement:  if a horizontal connection travels from left to
right, it must come from the right-most outlet of the upper object and
must connect to the left-most inlet of the lower object.  Reverse if
the connection travels from right to left.  The problem is there's no
good way to tell if a patch adheres to the agreement.

Matt

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


Re: [PD] ADSR variations [was: Re: Patch-off]

2009-03-21 Thread Jonathan Wilkes




--- On Sun, 3/22/09, Frank Barknecht  wrote:

> From: Frank Barknecht 
> Subject: Re: [PD] ADSR variations [was: Re: Patch-off]
> To: pd-list@iem.at
> Date: Sunday, March 22, 2009, 2:37 AM
> Hallo,
> Jonathan Wilkes hat gesagt: // Jonathan Wilkes wrote:
> 
> > I agree.  I also like the use of list in that patch to
> store parameters.
> > 
> > So if you wanted to set parameters with creation
> arguments, would it just be a matter of using $1...$5 in the
> [list]s and (un)[pack]?
> 
> Yes, almost. [list] is a shortcut for [list append] so you
> need to use: 
> [list append $1 $2 $3 $4 $5] or so.

Actually [list $1 $2 $3 $4 $5] seems to work in this context, but I guess 
that's because the first arg isn't a symbol.  Is that why you're saying [list 
append] is needed?

-Jonathan

> 
> Ciao
> -- 
> Frank
> 
> ___
> 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] multiple sound cards on XP?

2009-03-21 Thread John Harrison
Is there a way to get Pd to use multiple sound cards on XP? I've had no
problem doing this in Linux, but in XP on both Pd vanilla 0.42-4and
Pd-extended 0.40.3-extended-20080721, trying to configure MMIO with multiple
cards is giving me:

Terminal Window:

waveInOpen: The specified format is not supported or cannot be translated.
Use the Capabilities function to determine the supported formats.

Pd console:

separate audio device choice not supported\; using sequential devices.

and no input/output on both cards with one configuration.

If I choose ASIO, Pd crashes instantly with this message in the terminal
window:
Failed to open () = 0DEV not openDEV not openDeviceIoControl STOP_ISO_STREAM
com
plete, success = 0
DEV not openDEV not open

I have ASIO4ALL installed and did seem to have good luck with that in the
past on another machine...

I'd like to have multiple Griffin iMics plugged into an XP machine and all
accessible with one instance of Pd.

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


Re: [PD] ADSR variations [was: Re: Patch-off]

2009-03-21 Thread Frank Barknecht
Hallo,
Jonathan Wilkes hat gesagt: // Jonathan Wilkes wrote:

> I agree.  I also like the use of list in that patch to store parameters.
> 
> So if you wanted to set parameters with creation arguments, would it just be 
> a matter of using $1...$5 in the [list]s and (un)[pack]?

Yes, almost. [list] is a shortcut for [list append] so you need to use: 
[list append $1 $2 $3 $4 $5] or so.

Ciao
-- 
Frank

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


[PD] Horizontal Connections (Was: Re: style guide idea: [send foo] versus [; foo( )

2009-03-21 Thread Jonathan Wilkes

Hi Martin,

Here's my proposal: horizontal connections should only be used when the upper 
object has only one outlet, and the lower object has only one inlet.  Otherwise 
there will be always be ambiguity.

With your example of all outlets pointing to the same inlet, there is still 
ambiguity as to whether or not all the outlets are actually connected.  That's 
fine if your patching style is to connect them first, and only line them up 
after.  But if someone is debugs a patch they made that includes your 
abstraction, they would have to spend time moving objects to be certain 
everything is actually connected.

-Jonathan


--- On Sat, 3/21/09, Martin Peach  wrote:

> From: Martin Peach 
> Subject: Re: [PD] style guide idea: [send foo] versus [; foo(
> To: pd-list@iem.at
> Date: Saturday, March 21, 2009, 11:42 PM
> Frank Barknecht wrote:
> > Hallo,
> > Martin Peach hat gesagt: // Martin Peach wrote:
> > 
> >> It's a fun exercise for some kinds of mind to
> make all the non-vertical  lines either horizontal or 45
> degrees, as in the attached screen grab.
> > 
> > Ha, yeah, that's really cute!
> > 
> > Unfortunatly I clashes with another personal
> preference I have: avoiding
> > horizontal lines.
> 
> My personal preference says horizontal lines are all right
> as long as the connections are unambiguous. If a line passes
> across several outlets on the way to somewhere it's only
> acceptable when all the outlets are connected to the same
> inlet, so a bunch of messages to the same inlet could all be
> aligned on the same horizontal or diagonal line, but not
> vertical because then the message inlets would appear to be
> connected when they're not.
> 
> Martin
> 
> 
> ___
> 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] Horizontal Connections (Was: Re: style guide idea: [send foo] versus [; foo( )

2009-03-21 Thread Jonathan Wilkes

Hi Martin,

Here's my proposal: horizontal connections should only be used when the upper 
object has only one outlet, and the lower object has only one inlet.  Otherwise 
there will be always be ambiguity.

With your example of all outlets pointing to the same inlet, there is still 
ambiguity as to whether or not all the outlets are actually connected.  That's 
fine if your patching style is to connect them first, and only line them up 
after.  But if someone is debugs a patch they made that includes your 
abstraction, they would have to click and move objects to be certain all the 
objects are actually connected.

-Jonathan

--- On Sat, 3/21/09, Martin Peach  wrote:

> From: Martin Peach 
> Subject: Re: [PD] style guide idea: [send foo] versus [; foo(
> To: pd-list@iem.at
> Date: Saturday, March 21, 2009, 11:42 PM
> Frank Barknecht wrote:
> > Hallo,
> > Martin Peach hat gesagt: // Martin Peach wrote:
> > 
> >> It's a fun exercise for some kinds of mind to
> make all the non-vertical  lines either horizontal or 45
> degrees, as in the attached screen grab.
> > 
> > Ha, yeah, that's really cute!
> > 
> > Unfortunatly I clashes with another personal
> preference I have: avoiding
> > horizontal lines.
> 
> My personal preference says horizontal lines are all right
> as long as the connections are unambiguous. If a line passes
> across several outlets on the way to somewhere it's only
> acceptable when all the outlets are connected to the same
> inlet, so a bunch of messages to the same inlet could all be
> aligned on the same horizontal or diagonal line, but not
> vertical because then the message inlets would appear to be
> connected when they're not.
> 
> Martin
> 
> 
> ___
> 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] style guide idea: [send foo] versus [; foo(

2009-03-21 Thread Martin Peach

Frank Barknecht wrote:

Hallo,
Martin Peach hat gesagt: // Martin Peach wrote:

It's a fun exercise for some kinds of mind to make all the non-vertical  
lines either horizontal or 45 degrees, as in the attached screen grab.


Ha, yeah, that's really cute!

Unfortunatly I clashes with another personal preference I have: avoiding
horizontal lines.


My personal preference says horizontal lines are all right as long as 
the connections are unambiguous. If a line passes across several outlets 
on the way to somewhere it's only acceptable when all the outlets are 
connected to the same inlet, so a bunch of messages to the same inlet 
could all be aligned on the same horizontal or diagonal line, but not 
vertical because then the message inlets would appear to be connected 
when they're not.


Martin


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


Re: [PD] style guide idea: [send foo] versus [; foo(

2009-03-21 Thread Hans-Christoph Steiner


On Mar 21, 2009, at 3:42 AM, Matt Barber wrote:

Ah, ok, I get it, the text in the msg boxes is basically the same  
as the
text in the qlist file.  That makes sense, and in the context of  
[qlist] I
think it makes sense to teach about [; foo( sends.  But I don't  
think that
[qlist] is an essential object, especially for newbies.  I am not  
saying to
avoid it, I have covered it.  But personally, I almost never use  
it.  I find
it easier to use [textfile] and write my own timing code.  You can  
be a
pretty advanced Pd user and not have to use semi-colons in message  
boxes.


IMHO, semi-colons in messages boxes are no doubt useful, but they  
are not
essential.  In the interests of spreading out the learning of the  
concepts
in Pd into as many stages as possible, I think it makes sense to  
avoid using

semi-colons in messages boxes except in contexts that they are
indispensible.  So when learning about [qlist], for example, semi- 
colons in

message boxes should definitely be covered.

Outside of those contexts, I think that overall, Pd users will be  
better

served by avoiding their use.



I would have a hard time signing up for this program.  A lot of things
in Pd (and any programming language) are useful but inessential.

IMO the send/receive binding in messages is essential if you want to
understand how Pd is organized.  A lot depends on the kind of student
you're working with -- many of them don't feel comfortable with things
unless they see some kind of "big picture" -- for those students, they
would be comforted by the fact that message boxes can store "send"
messages, as well as [qlist] files, the text in .pd files, etc.
Eventually students will need to learn this stuff, so the occasional

| ;/
| pd dsp 1 \

serves as a handy reminder rather than a detriment to readability.


I agree that we should be teaching it, but if you've never done any  
programming whatsoever, and haven't learned about that syntax in Pd,  
then it is definitely a hinderance to learning Pd.  There are lots of  
useful concepts in Pd that are not trivial to learn.  If the newbie  
can be more gradually introduced to them, and have a cycle of attempts  
and successes, then they will be more willing later on to struggle to  
get something working.


If the newbie is hit with a stack of new concepts all at once, it  
makes it harder to have those successes in the beginning.  I also  
agree with you that once you are learning about messages and [qlist]  
that having reminders is useful.  But until then they often are a  
major stumbling block for newbies.


So I don't think everyone needs to avoid their use, but I do think  
that in the documentation and reference, we should avoid their use  
except in the contexts where they are directly relevant.  A great  
example is A04.line2.pd.  The three big message boxes are pretty  
impenetrable for someone with no programming experience.  Compare it  
to the [trigger bang anything bang] on the lower right.


And one last little story that I just remembered:  I didn't realize  
that [send pd] was even a possibility until recently.  I had always  
seen [; pd dsp 1( and figured messages to pd had to be sent that way.


.hc


A04.line2.pd
Description: Binary data





Part of the problem is that [; foo( is a misnomer.  It's

| ;/
| foo \

This is the only way the syntax is clear.

My vote for style goes for which makes the most sense in (often very
complex) context.

Matt






As we enjoy great advantages from inventions of others, we should be  
glad of an opportunity to serve others by any invention of ours; and  
this we should do freely and generously. - Benjamin Franklin



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


Re: [PD] ADSR variations [was: Re: Patch-off]

2009-03-21 Thread Jonathan Wilkes

I agree.  I also like the use of list in that patch to store parameters.

So if you wanted to set parameters with creation arguments, would it just be a 
matter of using $1...$5 in the [list]s and (un)[pack]?

-Jonathan

--- On Sat, 3/21/09, Kyle Klipowicz  wrote:

> From: Kyle Klipowicz 
> Subject: Re: [PD] ADSR variations [was: Re: Patch-off]
> To: pd-list@iem.at
> Date: Saturday, March 21, 2009, 4:08 PM
> Nice. As a side note, the ADSR variations patch of
> Frank's show very clearly
> how to use [vline~] correctly:
> $1=lvl, $2=attack time, $3=decay time, $4=sustain level.
> Go to $1 over $2 msec, go to $4 over $3 msec
> 
> Could use that in the vline~ help patch!
> 
> ~Kyle
> 
> On Sat, Mar 21, 2009 at 5:01 AM, Frank Barknecht
>  wrote:
> 
> > Hallo,
> > Frank Barknecht hat gesagt: // Frank Barknecht wrote:
> > > (For a strange reason my Iceweaselfirefox
> doesn't show the images for
> > > that article. My iPhone does, so they must be
> there. Can you see the
> > > images?)
> >
> > Never mind: Ad(sr)-blocking gone wrong...
> >
> > Ciao
> > --
> > Frank
> >
> >
> > ___
> > Pd-list@iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> > http://lists.puredata.info/listinfo/pd-list
> >
> 
> 
> 
> -- 
> -
> 
> -
>   - --
> http://perhapsidid.wordpress.com
> http://myspace.com/kyleklipowicz
> ___
> 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] style guide idea: [send foo] versus [; foo(

2009-03-21 Thread Frank Barknecht
Hallo,
Martin Peach hat gesagt: // Martin Peach wrote:

> It's a fun exercise for some kinds of mind to make all the non-vertical  
> lines either horizontal or 45 degrees, as in the attached screen grab.

Ha, yeah, that's really cute!

Unfortunatly I clashes with another personal preference I have: avoiding
horizontal lines.

Ciao
-- 
Frank

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


Re: [PD] style guide idea: [send foo] versus [; foo(

2009-03-21 Thread Frank Barknecht
Hallo,
Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:

> On Fri, 20 Mar 2009, Frank Barknecht wrote:
>
>> For example I'd rather start with making people properly left-align  
>> their patches and avoid crossing patch cords
>
> well, I do my best to reduce the number of crossings, but if I have to  
> avoid crossings completely, I'll just avoid Pd...
>
> Pd doesn't make it easy to avoid crossings.
>
> Not all crossings are even bad. Crossings that are ambiguous-looking are  
> very bad. Too many crossings in the same area is bad, except if the  
> crossings are very regular-looking (a line crossing a bunch of parallel  
> lines is more orderly than a line crossing a bunch of random-angled  
> lines).

Yeah, lets not turn a style guide into a style law.

Sometimes crossings are not avoidable indeed. You also have to weight
crossings against other layout questions, like preferring straight
vertical lines and left-alignment. I think, when laying out my patches
I seem to go like that: 

1) avoid crossings

2) if that doesn't work, then try to avoid patch cords crossing over
   objects, i.e. prefer cords crossing other cords only

3) if you really have to cross over objects, make the patch cords go
   in straight vertical lines (straight vertical cords are the best cords
   anyway)

4) even then avoid crossing over object inlets or outlets, as it is
   ambiguous which cords are connected.

Here's a patch that shows me failing all the way up to 3), but not 4):
http://footils.org/images/adsr-envelope-pipe.png

Ciao
-- 
 Frank BarknechtDo You RjDj.me?  _ __footils.org__

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


Re: [PD] a simple counter, I'm not able to do it tonight

2009-03-21 Thread patrick

hi,

in pdmtl abstractions there's [count.up&down]:
http://wiki.dataflow.ws/PdMtlAbstractions

video showing how to install it:
http://www.vimeo.com/psc

pat

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


Re: [PD] a simple counter, I'm not able to do it tonight

2009-03-21 Thread Frank Barknecht
Hallo,
Husk 00 hat gesagt: // Husk 00 wrote:

> Thank you all, but I expressed bad my necessity. I found a solution but
> still don't like it. I find inelgant and too much complex for what it has to
> do. I need a counter with two bang, first one for add one unit to the
> counter, second one for subtract one unit. Couter must have min and max
> limits, like 0 and 10 (for example). I attach my patch just like example,
> but as I said it's not a good solution.
> How should you do this?

Like in the attachement for example. It uses an accumulator idiom, which is a
reversed traditional counter where you exhange the [f ]x[+ 1] so it becomes
this instead: [+ ]x[f ]. Then drive it with -1 and 1. 

It's well explained in Andy Farnells fantastic Pd tutorial: 
http://aspress.co.uk/ds/pdf/DesigningSound_abridged_Pure_Data_introduction.pdf
Page 35.

Ciao
-- 
Frank
#N canvas 207 35 450 300 10;
#X obj 120 157 +;
#X obj 167 158 f;
#X msg 139 124 1;
#X msg 90 124 -1;
#X floatatom 120 213 5 0 0 0 - - -;
#X msg 139 95 up;
#X msg 90 96 down;
#X obj 120 241 hradio 15 1 0 11 empty empty empty 0 -8 0 10 -262144
-1 -1 0;
#X obj 120 189 clip 0 10;
#X connect 0 0 8 0;
#X connect 1 0 0 1;
#X connect 2 0 0 0;
#X connect 3 0 0 0;
#X connect 4 0 7 0;
#X connect 5 0 2 0;
#X connect 6 0 3 0;
#X connect 8 0 1 0;
#X connect 8 0 4 0;
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list


[PD] OSC controlled audio file player

2009-03-21 Thread alvaro
Hi all,

I just spawned a rather bombastic project, called OSCPlayer. The
complete description is on 

http://puredata.info/Members/alvarito/OSCPlayer

Here's the short version:

=

During the Radio1:1 (htp://www.radioeinszueins.de) experiment, Berlin,
June to August 2006, our team decided to build a broadcasting system
that would cover our special needs. 

As a programmer, the mayor difficulty I had to face was the lack of a
player that could be controlled remotely through a standard protocol. I
finally settled for writing plug-ins for the Icecast streaming server.

While this worked as a temporary solution, it was apparent right from
the start that we were missing a central component: a player that would
take commands from a scheduler, do crossfades, switch to a life stream
or streams from external sources, blend in the station jingle, do
dynamic range compression, and then pipe the output to Icecast. 

While Puredata is not the obvious choice for building such a player,
such an implementation can be an excellent prototype as well as a
reference, and IMHO an interesting experiment.



WOW am I going to bother you with questions during the next couple of
months. Any kind of input much appreciated.

Best,
Alvaro


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


Re: [PD] a simple counter, I'm not able to do it tonight

2009-03-21 Thread Ben Baker-Smith
Check out the attached patch, more what you're looking for?

-Ben


Message: 3
Date: Sat, 21 Mar 2009 14:59:26 +0100
From: Husk 00 
Subject: Re: [PD] a simple counter, I'm not able to do it tonight
To: pd list 
Message-ID:
   
Content-Type: text/plain; charset="iso-8859-1"

Thank you all, but I expressed bad my necessity. I found a solution but
still don't like it. I find inelgant and too much complex for what it has to
do. I need a counter with two bang, first one for add one unit to the
counter, second one for subtract one unit. Couter must have min and max
limits, like 0 and 10 (for example). I attach my patch just like example,
but as I said it's not a good solution.
How should you do this?
cheers
Husk


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


Re: [PD] default [output~] in Pd-extended

2009-03-21 Thread Steffen Juul

To cut a longer story short:

- No i don't want everyone to live there life linearly. How could  
that at all be assumed. (I rather embrace the opposite.)


- The Pd tutorials that Miller ship with Pd is bottom-up. That is the  
didactic contract with the reader. So if you want a canvas'ified-gui- 
volume-control with such use of canvas with graph-on-parent, it need  
be introduced first. That could be done in the "2.control.examples"  
section.



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


[PD] A patch to share

2009-03-21 Thread Pall Thayer
I was going through some old stuff on my computer and found this  
patch I made a few years ago for a project called Autodrawn. The  
piece used to run on my server but due to my laziness in updating or  
even upgrading my server it's no longer running. However, the PD  
patch that goes with the work is interesting so I want to share it  
with the community. I've loosely applied the GPL to it. It might not  
be an interesting technical feat but rather conceptually. It plays a  
repeated sequence from Kraftwerk's Autobahn interspersed with live  
mp3 feeds of police scanners. The idea was to take the idea of the  
autobahn as portrayed on the original album cover, as something  
beautifully peaceful and positive and turn it into a more modern view  
of the freeway as something ominous and dangerous which has taken on  
an even newer meaning in recent years as a symbol of the negative  
impacts our fossil fuel consumption is having on the environment.  
Also, I just think it sounds cool. Even though it's just playing the  
same short sequence over and over again, it's still fun to listen to  
for long periods of time.


So, if you find something interesting to do with it, feel free.

best r.
Pall Thayer


#N canvas 4 98 985 512 10;
#X obj 149 96 mp3amp~;
#X msg 19 70 disconnect;
#X floatatom 193 123 5 0 0 0 - - -;
#X obj 234 96 vsl 15 128 0 1 0 0 empty empty empty 0 -8 0 8 -262144
-1 -1 0 1;
#X obj 327 108 mp3amp~;
#X msg 264 86 disconnect;
#X floatatom 371 135 5 0 0 0 - - -;
#X obj 412 108 vsl 15 128 0 1 0 0 empty empty empty 0 -8 0 8 -262144
-1 -1 0 1;
#X obj 466 123 delread~ dc 400;
#X obj 466 167 delwrite~ dc 400;
#X floatatom 466 105 5 0 0 0 - - -;
#X obj 12 104 delread~ sas 400;
#X obj 12 148 delwrite~ sas 400;
#X obj 471 145 *~ 0.1;
#X obj 17 126 *~ 0.1;
#X obj 149 306 mp3amp~;
#X msg 86 269 disconnect;
#X floatatom 193 333 5 0 0 0 - - -;
#X obj 234 306 vsl 15 128 0 1 0 0 empty empty empty 0 -8 0 8 -262144
-1 -1 0 1;
#X floatatom 322 334 5 0 0 0 - - -;
#X obj 327 374 *~ 0.1;
#X obj 322 352 delread~ sw 400;
#X obj 322 396 delwrite~ sw 400;
#X obj 544 326 f;
#X obj 615 326 + 1;
#X obj 683 274 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 1
1;
#X floatatom 563 378 5 0 0 0 - - -;
#N canvas 0 22 450 300 (subpatch) 0;
#X array array103 100 float 1;
#A 0 68 61 0 73 66 0 0 0 0 75.7258 75.7258 75.7258 73.1658 68.0458
65.4858 65.4858 66.3391 67.1925 68.0458 68.0458 68.0458 62.9258 61.6458
60.3658 57.8058 55.2458 52.6858 50.1258 47.5658 45.0058 42.4458 39.8857
38.1791 36.4724 34.7658 33.0591 31.3524 29.6457 27.0857 24.5257 21.9657
19.4057 18.1257 16.8457 16.8457 14.2857 14.2857 9.16572 4.04571 1.50713
1.54285 45.082 50.202 47.642 47.642 47.642 47.642 47.642 48.4953 49.3486
50.202 51.0553 51.9086 52.762 54.042 55.322 56.602 57.882 59.162 60.442
61.722 63.002 64.282 65.562 66.842 68.122 68.122 68.122 68.122 80.922
-0.385712 -0.414283 -0.45714 -0.47 -0.528568 -0.585711 -0.57
-0.614282 0 100 50 78 54 0 0 0 0 0 0 0;
#X coords 0 128 99 0 100 50 1;
#X restore 619 176 graph;
#X obj 547 347 tabread array103;
#X obj 594 437 line;
#X obj 525 459 *~;
#X obj 521 392 mtof;
#X obj 487 371 mtof;
#X obj 487 393 osc~;
#X obj 448 371 mtof;
#X obj 681 370 route 0;
#X obj 569 326 mod 8;
#X msg 496 234 \; array103 0 68 61 0 73 66 0 0 0;
#X obj 448 393 osc~;
#X obj 521 414 osc~;
#X obj 447 347 - 24;
#X obj 486 347 - 12.1;
#X obj 31 413 delwrite~ autob 450;
#X obj 18 353 delread~ autob 450;
#X obj 682 302 metro 300;
#X obj 628 44 f;
#X obj 699 44 + 1;
#X obj 653 44 mod 2;
#X floatatom 657 76 5 0 0 0 - - -;
#X obj 612 393 delay 5;
#X obj 740 38 delay 5000;
#X obj 342 53 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1
-1;
#X obj 361 44 delay 5000;
#X obj 737 60 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1
-1;
#X obj 496 13 metro 30;
#X obj 657 103 route 0 1;
#X obj 657 125 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1
-1;
#X obj 686 125 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1
-1;
#X obj 715 125 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1
-1;
#X obj 49 2 delay 5000;
#X obj 126 44 delay 5000;
#X obj 762 153 route 0 1;
#X obj 762 175 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1
-1;
#X obj 791 175 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1
-1;
#X obj 820 175 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1
-1;
#X obj 323 24 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1
-1;
#X obj 22 2 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 -1
;
#X obj 761 127 pipe 6;
#X obj 103 47 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1
-1;
#X obj 146 150 *~ 0.4;
#X obj 146 360 *~ 0.23;
#X obj 324 162 *~ 0.33;
#X msg 286 306 connecturl http://12.40.197.36:8000;
#X obj 794 250 route 0 1;
#X obj 794 272 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1
-1;
#X obj 823 272 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1
-1;
#X obj 852 272 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1
-1;
#X obj 793 224 pipe 8;
#X obj 766 255 bng 1

Re: [PD] a simple counter, I'm not able to do it tonight

2009-03-21 Thread husk

Jack escribió:

Hoping it will help you in the building of your counter.
++

Jack

The B example is perfect!
thank you Jack

cheers
Husk

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


Re: [PD] ADSR variations [was: Re: Patch-off]

2009-03-21 Thread Kyle Klipowicz
Nice. As a side note, the ADSR variations patch of Frank's show very clearly
how to use [vline~] correctly:
$1=lvl, $2=attack time, $3=decay time, $4=sustain level.
Go to $1 over $2 msec, go to $4 over $3 msec

Could use that in the vline~ help patch!

~Kyle

On Sat, Mar 21, 2009 at 5:01 AM, Frank Barknecht  wrote:

> Hallo,
> Frank Barknecht hat gesagt: // Frank Barknecht wrote:
> > (For a strange reason my Iceweaselfirefox doesn't show the images for
> > that article. My iPhone does, so they must be there. Can you see the
> > images?)
>
> Never mind: Ad(sr)-blocking gone wrong...
>
> Ciao
> --
> Frank
>
>
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>



-- 
-

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


Re: [PD] a simple counter, I'm not able to do it tonight

2009-03-21 Thread Jack
Hoping it will help you in the building of your counter.++Jack

counter.pd
Description: Binary data
Le 21 mars 09 à 14:59, Husk 00 a écrit :Thank you all, but I expressed bad my necessity. I found a solution but still don't like it. I find inelgant and too much complex for what it has to do. I need a counter with two bang, first one for add one unit to the counter, second one for subtract one unit. Couter must have min and max limits, like 0 and 10 (for example). I attach my patch just like example, but as I said it's not a good solution. How should you do this?cheers HuskBen Baker-Smith On Wed, Mar 18, 2009 at 8:38 PM, Ben Baker-Smith  wrote: So you want a counter that counts to 100 and then begins at 0 (or 1) again?If I'm understanding correctly I would do the following: [bang(|[float]X[+ 1]|[select 100]|[0( the 0 message at the end could also be a 1 depending on if you want the counter to begin on 0 or 1, it is sent to the right inlet of float.the outlet of float is, in addition to [select], also sent wherever you want the counter to be output to. here is the same patch as a subpatch (keeping in mind that the 0 message still must be connected to the right inlet of float):[inlet]|[b]|[float]X[+ 1]| \| [outlet]|[select 100] |[0(...of course you can always use the [counter] object.  [counter 100] will probably do the trick all by itself.and finally, if i'm understanding incorrectly and you wanted it to count up and back down, use the example that was posted previously with the absolute values and [wrap], or use [counter 100] with the up/down message sent to it, you'll have to check the help file for exactly what that message is...hope something in there helps.-Ben ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list ___Pd-list@iem.at mailing listUNSUBSCRIBE 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] default [output~] in Pd-extended

2009-03-21 Thread Kyle Klipowicz
I took Modern Algebra as my first course in "Higher Math." Big mistake.
Learning to do proofs this way is a big headache, especially if you have a
curmudgeonly teacher!
~Kyle

On Sat, Mar 21, 2009 at 9:28 AM, Mathieu Bouchard wrote:

> On Sat, 21 Mar 2009, Steffen Juul wrote:
>
>> Unveiled mysteries are indeed good, yes, we could almost define it as
>> learning. But did you learn Modern Algebra before Linear Algebra?
>>
>
> What I recall is that the first course of Modern Algebra (Group Theory)
> didn't really use much of anything from Linear Algebra, but the second
> course did. Your university may vary...
>
> Basically, there's not much in a math degree curriculum that requires
> Linear Algebra to be taught first. I could very well see one that teaches
> Modern Algebra first, and it wouldn't be a scandal to me. There are probably
> universities that do, somewhere -- at least if they are as experimental as
> they are in compsci... some universities teach computer programming in quite
> wild ways.
>
> So, what's your point about unveiled mysteries?
>
>  _ _ __ ___ _  _ _ ...
> | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>


-- 
-

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


[PD] Qeve - free your visualz!

2009-03-21 Thread Husk 00
I list,
i would like to share with you all my last work with PD. It is a Vj like
App, developed by me and others this last year, with economic support of
Catalan videomaker associacion Telenoika (telenoika.net) and Hangar - centre
de producciò de arts visuals (www.hangar.org) support.
 IT's called Qeve (Cu-Eve), and it's still a beta (with a lot of bugs :().
I use it on all my gig with very good results; I used it in many workshop
too between Italy and Spain, as a tool for introducing PD programming to not
programmer Vjs. It's based on pdp and pdp_opengl. It's basically a 3 channel
mixer where every channel could be one of 5 different type of players:
video, 3d generator, image, paint, text. You can change player in real time
mixing different kind of source. It has audio analisys and BPM master clock,
and give the possibility to connect every propierty of any player to  music
or  BPM.
It still miss of documentation, i'm on it. But if you are interested I can
help you to run it.
This is my develop blog:
http://qeve.estereotips.net

I hope it could interest you.
bye
Husk
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] default [output~] in Pd-extended

2009-03-21 Thread Mathieu Bouchard

On Sat, 21 Mar 2009, Steffen Juul wrote:
Unveiled mysteries are indeed good, yes, we could almost define it as 
learning. But did you learn Modern Algebra before Linear Algebra?


What I recall is that the first course of Modern Algebra (Group Theory) 
didn't really use much of anything from Linear Algebra, but the second 
course did. Your university may vary...


Basically, there's not much in a math degree curriculum that requires 
Linear Algebra to be taught first. I could very well see one that teaches 
Modern Algebra first, and it wouldn't be a scandal to me. There are 
probably universities that do, somewhere -- at least if they are as 
experimental as they are in compsci... some universities teach computer 
programming in quite wild ways.


So, what's your point about unveiled mysteries?

 _ _ __ ___ _  _ _ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] a simple counter, I'm not able to do it tonight

2009-03-21 Thread Husk 00
Thank you all, but I expressed bad my necessity. I found a solution but
still don't like it. I find inelgant and too much complex for what it has to
do. I need a counter with two bang, first one for add one unit to the
counter, second one for subtract one unit. Couter must have min and max
limits, like 0 and 10 (for example). I attach my patch just like example,
but as I said it's not a good solution.
How should you do this?
cheers
Husk

Ben Baker-Smith 
On Wed, Mar 18, 2009 at 8:38 PM, Ben Baker-Smith wrote:

> So you want a counter that counts to 100 and then begins at 0 (or 1) again?
>
> If I'm understanding correctly I would do the following:
>
> [bang(
> |
> [float]X[+ 1]
> |
> [select 100]
> |
> [0(
>
>
> the 0 message at the end could also be a 1 depending on if you want the
> counter to begin on 0 or 1, it is sent to the right inlet of float.
>
> the outlet of float is, in addition to [select], also sent wherever you
> want the counter to be output to.
>
> here is the same patch as a subpatch (keeping in mind that the 0 message
> still must be connected to the right inlet of float):
>
> [inlet]
> |
> [b]
> |
> [float]X[+ 1]
> | \
> | [outlet]
> |
> [select 100]
> |
> [0(
>
> ...of course you can always use the [counter] object.  [counter 100] will
> probably do the trick all by itself.
> and finally, if i'm understanding incorrectly and you wanted it to count up
> and back down, use the example that was posted previously with the absolute
> values and [wrap],
> or use [counter 100] with the up/down message sent to it, you'll have to
> check the help file for exactly what that message is...
>
> hope something in there helps.
>
> -Ben
> 
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>


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


Re: [PD] default [output~] in Pd-extended

2009-03-21 Thread Hans-Christoph Steiner


On Mar 21, 2009, at 12:07 PM, IOhannes m zmoelnig wrote:


Steffen Juul wrote:


On 21/03/2009, at 3.44, Hans-Christoph Steiner wrote:



On Mar 11, 2009, at 8:42 AM, IOhannes m zmoelnig wrote:


but myteries unveiled are good for learning.
so it boils down to in-line documentation of the mysteries used.


Unveiled mysteries are indeed good, yes, we could almost define it as
learning. But did you learn Modern Algebra before Linear Algebra?


i don't think i can follow you here.
it seems like you want to keep people from teaching "Modern Algebra"
because the students might not have learned "Linear Algebra" yet.
this leaves us at learning only the most simplistic ideas, unless we  
can

enforce people to encounter mysteries only at well defined places in
their life.

i think most RPG work like this. i would prefer my life to be less  
linear.






So here's my attempt at a vanilla combination of Miller's output~,
rradical/ezdac~, and pddp/dsp.


I find that quite confusing. I can't say i know how it works.


i can only tell you that it is buggy: if you "mute" and then adjust to
valume (in "mute" state), and then "mute" again it doesn't do  
anything.

probably this makes it harder to understand.


Now with fixed mute and outlet~s



ezoutput~-help.pd
Description: Binary data


ezoutput~.pd
Description: Binary data



.hc





As we enjoy great advantages from inventions of others, we should be  
glad of an opportunity to serve others by any invention of ours; and  
this we should do freely and generously. - Benjamin Franklin



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


Re: [PD] default [output~] in Pd-extended

2009-03-21 Thread IOhannes m zmoelnig
Steffen Juul wrote:
> 
> On 21/03/2009, at 3.44, Hans-Christoph Steiner wrote:
> 
>>
>> On Mar 11, 2009, at 8:42 AM, IOhannes m zmoelnig wrote:
>>>
>>> but myteries unveiled are good for learning.
>>> so it boils down to in-line documentation of the mysteries used.
> 
> Unveiled mysteries are indeed good, yes, we could almost define it as
> learning. But did you learn Modern Algebra before Linear Algebra?

i don't think i can follow you here.
it seems like you want to keep people from teaching "Modern Algebra"
because the students might not have learned "Linear Algebra" yet.
this leaves us at learning only the most simplistic ideas, unless we can
enforce people to encounter mysteries only at well defined places in
their life.

i think most RPG work like this. i would prefer my life to be less linear.


> 
>> So here's my attempt at a vanilla combination of Miller's output~,
>> rradical/ezdac~, and pddp/dsp.
> 
> I find that quite confusing. I can't say i know how it works.

i can only tell you that it is buggy: if you "mute" and then adjust to
valume (in "mute" state), and then "mute" again it doesn't do anything.
probably this makes it harder to understand.


gfamrd
IOhannes

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


Re: [PD] ADSR variations [was: Re: Patch-off]

2009-03-21 Thread Frank Barknecht
Hallo,
Frank Barknecht hat gesagt: // Frank Barknecht wrote:
> (For a strange reason my Iceweaselfirefox doesn't show the images for
> that article. My iPhone does, so they must be there. Can you see the
> images?)

Never mind: Ad(sr)-blocking gone wrong...

Ciao
-- 
Frank
 

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


Re: [PD] sigmund~ env output

2009-03-21 Thread Oded Ben-Tal




Hmm - there shouldn't be any difference between sigmund~'s env output and
that of env~.  What latform are you on?  Perhaps I should check this out.



This is on the winXP version.
thanks
Oded

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


[PD] ADSR variations [was: Re: Patch-off]

2009-03-21 Thread Frank Barknecht
Hallo,
Jonathan Wilkes hat gesagt: // Jonathan Wilkes wrote:

> Ok, I'd like to propose a "patch-off."
> 
> What's the cleanest, clearest way to present adsr.pd from the audio tutorials?
> 
> I choose this patch because there are lots of crossed wires, plus one has to 
> leave space for the explanatory comments of the patch.
> 
> Here are two versions I could think of.

Nice idea. I wrote up two alternative aproaches to ADSRing in Pd here:
http://footils.org/cms/weblog/2009/mar/21/adsr-envelopes-pd/

My patch-off is this: http://footils.org/pkg/adsr-variations.pd

(For a strange reason my Iceweaselfirefox doesn't show the images for
that article. My iPhone does, so they must be there. Can you see the
images?)

Ciao
-- 
 Frank BarknechtDo You RjDj.me?  _ __footils.org__

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


Re: [PD] default [output~] in Pd-extended

2009-03-21 Thread Steffen Juul


On 21/03/2009, at 3.44, Hans-Christoph Steiner wrote:



On Mar 11, 2009, at 8:42 AM, IOhannes m zmoelnig wrote:


but myteries unveiled are good for learning.
so it boils down to in-line documentation of the mysteries used.


Unveiled mysteries are indeed good, yes, we could almost define it as  
learning. But did you learn Modern Algebra before Linear Algebra?


So here's my attempt at a vanilla combination of Miller's output~,  
rradical/ezdac~, and pddp/dsp.


I find that quite confusing. I can't say i know how it works.


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