Re: [PD] Call for GSoC mentors! March 9th deadline!

2009-03-04 Thread danomatika

Do you think a valid project would be to debug pd / pd-extended 64 bit
builds?  After losing a few days trying to get a solid 64 build of pd
+externals, I'm a bit disappointed at the current state.  It's something
rather boring, but would be quite useful for the future ... the next OSX
(Snow Leaopard), for instance will be natively 64bit.  (I assume for
asking the question, I would need to be the mentor?)

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


Re: [PD] pd and tcp: what to do against crashes?

2009-03-04 Thread Roman Haefeli
On Wed, 2009-03-04 at 09:14 -0500, Martin Peach wrote:

> > martin, would you mind implementing similar changes to [tcpclient] as
> > well?
> > 
> > 
> 
> I'll do that today if I have time.

yo... no hurry.. but it seems you already did it. many thanks. 

those changes to [tcpserver] and [tcpclient] enable me to solve a _lot_
of issues with netpd (which currently is still based on
[netclient]/[netserver]). some of them were very long standing problems,
such as server hangs, and it took me also a long time to understand the
underlying causes for those problems. i am very satisfied to see, that
the current problems can be addressed now.

i think there is nothing left to be said for now. it's definitely time
to get my hands dirty again on the netpd-server and other related
stuff. 

many thanks for your cooperation.

roman



___ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de


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


[PD] pd~ to sync audio/video

2009-03-04 Thread Max

hi list,

i am trying out if the pd~ object is an alternative for sync playback  
of audio and video to the “traditional” method of using two instances  
of pd talking to each other by netserver/netclient.


so the situation is that we need one pd instance with audio on and one  
without for gem.
because audio needs to run without dropouts in the first process,  
while gem will run in the second process.


to run the video in the parent process and the audio in the subprocess  
with pd~ doesn't work, because the main process needs audio on. (see  
pd~ helppatch the last lines)


to run the audio in the parent process and the video in the subprocess  
using pd~ -noutsig 0 -ninsig 0 doesn't work because pd freezes when  
using these parameters on pd~


when using pd~-noutsig 0 it does work, but only if the subprocess will  
switch its dsp computing on for a moment it can be switched of  
afterwards.


is it a good idea at all to use pd~ for that purpose or should i stick  
to the netserver/netclient solution?


m. 

PGP.sig
Description: Signierter Teil der Nachricht
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list


[PD] scheme or common lisp object?

2009-03-04 Thread padovani
Is there some scheme or CL object running in PD? k_guile seems to be 
inactive, or am I wrong?

-- 
http://www.padovani.googlepages.com


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


Re: [PD] flext on os X

2009-03-04 Thread Loic Kessous
Hi,

oups. sorry I missed it...

As I said everything is OK on os X for building flex,  and I also can  
build a copied/modified version of the simple1 tutorial (called  
simplo1 with a 'o') to test my installation., and everything is ok.

I did the same thing on linux ubuntu hardy , and I also been able to  
build  flex, and the same copy of simple1, but when using it I get  
this bug :

- if I open the help file for simple1 , or even one that I edited in  
text mode to change simple1 to simplo1 , bot of them are working.

- BUT if I try to create one of them from scratch, by just doing:   
File > new, Put>object and typing the name , then Pd is out of order  
and I just can quit it. (Pd-extended 0.40.3)
the ubuntu is running on a AMD 64 bit, running a 32 bit ubuntu hardy  
(and except this bug everything seems ok)

I remember that for the optimisation flag in the config file when I  
installed flex, I didn't changed the 'pentium4' suggested because most  
of the other things that installed where also described as 'this is  
for intel' but where working.

  could it be this? should I re-install flext again by let it blank ?  
or put something instead of 'pentium4' ? and what?


loic



On Mar 4, 2009, at 9:01 PM, Thomas Grill wrote:

> Hi Loic,
> please direct all flext-related mails to the mailing list.
>
>
> Am 04.03.2009 um 19:53 schrieb Loic Kessous:
>
>>
>> I suppose if I was connected as root this would have not be a  
>> problem but I wonder if it would not be a problem then to run  
>> it...I don't know...
>>
>> anyway, this may help others to add the precision somewhere  
>> build.txt or somewher else.
>>
>
> did you check out flext from the svn (which is the latest version)?
> It's all in build.txt, just below the install commands.
>
> gr~~~
>


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


Re: [PD] httpget: fun with tcpclient and pdstring

2009-03-04 Thread Bryan Jurish
adding this to the GSoC ideas wiki...

actually, there's some disabled table-storage code in [pdstring] as
well; perhaps I'll get a chance to polish that up sometime soon..

marmosets,
Bryan

On 2009-03-04 19:01:31, Hans-Christoph Steiner  appears to
have written:
> It seems that we should have a string.h for tables then.  That would  
> be a good starting point, just make a library that is just Pd  
> interpretations of all the string.h strcpy, etc. functions, but have  
> them operate on arrays and maybe lists of floats too.
> 
> There could also be a totally Pd-ish string library too.

-- 
Bryan Jurish   "There is *always* one more bug."
jur...@ling.uni-potsdam.de  -Lubarsky's Law of Cybernetic Entomology

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


Re: [PD] httpget: fun with tcpclient and pdstring

2009-03-04 Thread Hans-Christoph Steiner

On Mar 4, 2009, at 11:46 AM, Martin Peach wrote:

> Mathieu Bouchard wrote:
>> On Wed, 4 Mar 2009, Martin Peach wrote:
>>
>>> That's nice. Now we need some html parsing objects so the pages go  
>>> into the patch and not the pd window. It works well if the  
>>> received pages are loaded into a table. I made tabfind to search a  
>>> table for a string. Tables seem more efficient than lists and less  
>>> volatile.
>>
>> Lists are volatile because they are (typically) stack-allocated or  
>> in any way their contract of use makes (argc,argv) only valid  
>> during the call... so you could use a heap-allocated argv but  
>> modify it between calls and it would still make the list data have  
>> a stack-wise accessibility.
>>
>> Because lists are volatile, they need to be copied by any object  
>> that wants to keep them. It's actually worse than that, as objects  
>> used recursively have to watch out for what they can deallocate.  
>> It's not like you could make [list] be faster without complicating  
>> it... and this includes plain data-recursion as well too (set cold- 
>> inlet of an object while its cold-inlet has still a job pending on  
>> the stack).
>>
>> Tables can be much faster but they also need to be statically- 
>> allocated (or dynamically-patched!), and they are type-restricted  
>> (where you can't say that any element slot may contain any atom one  
>> decides at runtime), and you have to find names for the tables  
>> because they can't be anonymous.
>
> Tables also use half as much memory as lists because they are mainly  
> an array of floats, while a list of floats is actually an array of  
> atoms, each atom comprising a tag indicating that it contains a  
> float as well as the float itself.
> For the network objects the lists are made of floats so the type  
> restriction is not important.
> Also a table can be reused and resized and its contents never get  
> added to the symbol list so there's no constantly increasing memory  
> involved. The typical web page has a huge amount of irrelevant text  
> that would quickly clog the symbol table, so it's more efficient to  
> extract the relevant bits before converting any of it to a symbol.


It seems that we should have a string.h for tables then.  That would  
be a good starting point, just make a library that is just Pd  
interpretations of all the string.h strcpy, etc. functions, but have  
them operate on arrays and maybe lists of floats too.

There could also be a totally Pd-ish string library too.

.hc






'You people have such restrictive dress for women,’ she said, hobbling  
away in three inch heels and panty hose to finish out another pink- 
collar temp pool day.  - “Hijab Scene #2", by Mohja Kahf



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


Re: [PD] httpget: fun with tcpclient and pdstring

2009-03-04 Thread Martin Peach
Mathieu Bouchard wrote:
>On Wed, 4 Mar 2009, Martin Peach wrote:
>
>>That's nice. Now we need some html parsing objects so the pages go into 
>>the patch and not the pd window. It works well if the received pages are 
>>loaded into a table. I made tabfind to search a table for a string. Tables 
>>seem more efficient than lists and less volatile.
>
>Lists are volatile because they are (typically) stack-allocated or in any 
>way their contract of use makes (argc,argv) only valid during the call... 
>so you could use a heap-allocated argv but modify it between calls and it 
>would still make the list data have a stack-wise accessibility.
>
>Because lists are volatile, they need to be copied by any object that wants 
>to keep them. It's actually worse than that, as objects used recursively 
>have to watch out for what they can deallocate. It's not like you could 
>make [list] be faster without complicating it... and this includes plain 
>data-recursion as well too (set cold-inlet of an object while its 
>cold-inlet has still a job pending on the stack).
>
>Tables can be much faster but they also need to be statically-allocated (or 
>dynamically-patched!), and they are type-restricted (where you can't say 
>that any element slot may contain any atom one decides at runtime), and you 
>have to find names for the tables because they can't be anonymous.

Tables also use half as much memory as lists because they are mainly an 
array of floats, while a list of floats is actually an array of atoms, each 
atom comprising a tag indicating that it contains a float as well as the 
float itself.
For the network objects the lists are made of floats so the type restriction 
is not important.
Also a table can be reused and resized and its contents never get added to 
the symbol list so there's no constantly increasing memory involved. The 
typical web page has a huge amount of irrelevant text that would quickly 
clog the symbol table, so it's more efficient to extract the relevant bits 
before converting any of it to a symbol.

Martin



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


Re: [PD] streaming audio and video in Linux

2009-03-04 Thread ydego...@gmail.com
ola,
>
> i am not complaining too much because i am pretty happy this is just working 
> in general... i am just looking to make it a little more efficient and i am a 
> little confused over all the yuv/yv12 stuff that is going on and why i have 
> to convert to rgb and back to yuv just to get it to work right - with the 
> understanding pdp/yuv is the fastest and most efficient.
>   
yes, pdp was all coded mostly in yuv since the beginning
for efficiency and speed reasons,
so we have to pass throough conversions
to connect to other pieces of code.
> BTW the piping stuff is really killer! although i have only been able to get 
> it to work on linux... osx gives me a wicked big file that continuously 
> increases in size as the stream is converted. linux just makes a 0k tmp/pipe 
> that is very nice. i guess this is just a mencoder thing on osx obviously.
>   
interesting bug, but it means it's not compàtible
with linux standards then, humm..
no osx here ( in all the house )

xiaoo,
sevy
> thanks!
> m
>   
>
>
>   


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


Re: [PD] evaluate 3d iterative structures

2009-03-04 Thread Mathieu Bouchard

On Wed, 4 Mar 2009, simeon cosik wrote:


hello, thanks for the reply, are you telling me to take off all the
positions of all the geos and then evaluate in other program?


No, I only talked about how you are going to extract the positions out of 
the usual [gemhead] chains so that you can use them in whichever other way 
you want, which could be using pmpd, msd, gridflow, iemmatrix, pyode or 
whatever else.


I just checked there is a Ode version that run in pd , called pyode, i 
think ode works fine for rigid body simulations, do you think this is a 
good option in pd?


no idea.

 _ _ __ ___ _  _ _ ...
| 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] list issue

2009-03-04 Thread Mathieu Bouchard

On Wed, 4 Mar 2009, YOhannes wrote:

what i want to do is to put them randomly into the list as long as the 
sum of all items in the list equals the size of the fixed value. this 
seems to be pretty difficult...since i use random i cant know what the 
next float will be. how to handle that? any experience with that issue ?


Make a random recursive partition of the fixed value, then shuffle it.

For example:

* start with the list 16 (one element)

* for each number in the list, throw dice to figure out whether you will
  replace it by two equal numbers. any new numbers shall have the same
  procedure reapplied to them (recursion), else I wouldn't be
  explaining it by saying "for each" when it's about a one-element list.
  this could give you, for example: 4 1 1 0.5 0.5 1 2 1 1 0.5 0.5 1 2

* a fair shuffle could give any sequence with the same number of 0.5,1,2,4 
elements in it, let's say 0.5 4 1 1 0.5 2 1 0.5 2 1 0.5 1 1.


 _ _ __ ___ _  _ _ ...
| 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] httpget: fun with tcpclient and pdstring

2009-03-04 Thread Hans-Christoph Steiner

On Mar 4, 2009, at 9:18 AM, Martin Peach wrote:

> Hans-Christoph Steiner wrote:
>> I made [httpget] for fetching webpages into pd:
>
>
> That's nice. Now we need some html parsing objects so the pages go  
> into the patch and not the pd window. It works well if the received  
> pages are loaded into a table. I made tabfind to search a table for  
> a string. Tables seem more efficient than lists and less volatile.


Any ideas on how to approach the HTML parsing?  It seems like using an  
xml-based parsing library would be the way to do that.  There is detox  
in jasch_lib, but I don't know the state of it.

.hc




"[W]e have invented the technology to eliminate scarcity, but we are  
deliberately throwing it away to benefit those who profit from  
scarcity."-John Gilmore



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


Re: [PD] httpget: fun with tcpclient and pdstring

2009-03-04 Thread Mathieu Bouchard

On Wed, 4 Mar 2009, Martin Peach wrote:

That's nice. Now we need some html parsing objects so the pages go into 
the patch and not the pd window. It works well if the received pages are 
loaded into a table. I made tabfind to search a table for a string. 
Tables seem more efficient than lists and less volatile.


Lists are volatile because they are (typically) stack-allocated or in any 
way their contract of use makes (argc,argv) only valid during the call... 
so you could use a heap-allocated argv but modify it between calls and it 
would still make the list data have a stack-wise accessibility.


Because lists are volatile, they need to be copied by any object that 
wants to keep them. It's actually worse than that, as objects used 
recursively have to watch out for what they can deallocate. It's not like 
you could make [list] be faster without complicating it... and this 
includes plain data-recursion as well too (set cold-inlet of an object 
while its cold-inlet has still a job pending on the stack).


Tables can be much faster but they also need to be statically-allocated 
(or dynamically-patched!), and they are type-restricted (where you can't 
say that any element slot may contain any atom one decides at runtime), 
and you have to find names for the tables because they can't be anonymous.


 _ _ __ ___ _  _ _ ...
| 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] Pd seriell printers

2009-03-04 Thread Mathieu Bouchard

On Wed, 4 Mar 2009, bra...@subnet.at wrote:

On 3 Mar 2009, ma...@artengine.ca wrote:

I know nothing about this printer in particular, but if it's a new machine
with a RS232 port, I suspect that it's because of systems that still use
the old Epson protocol:

yes it is a new one. And now I will check the papers


yes I understood that it's a new one, I just mean "for any new machines 
with a RS232 port, it's probably because of systems that still use the old 
Epson protocol". I say that so that you understand my reasoning. You could 
use that idea to pick different hardware if you need to or if you find any 
other reason why anything else would be better.


 _ _ __ ___ _  _ _ ...
| 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] streaming audio and video in Linux

2009-03-04 Thread mark edward grimm

so i did get this working on linux with mencoder + pdp_rawin using code:

#! /bin/sh
rm /tmp/pipe
mknod /tmp/pipe p
mencoder -nosound -ovc raw -of rawvideo -vf scale,format=rgb24 
mms://ph.wm.live05.pscdn.net/00302597_live12?MSWMExt=.asf -o /tmp/pipe

although i am finding this might be inefficient having to convert colorspace 
from  yuv -> rgb -> yuvthe only way i have been able to get this to work is 
to do this. i am not sure why, admitting i am limited in my understanding of 
colorspace.

>From mencoder i get something like:

Decoder is capable of YUV output (flags 0x1b)
VDec: vo config request - 320 x 240 (preferred colorspace: Packed YUY2)
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is undefined - no prescaling applied.
[swscaler @ 0x883e3d0]No accelerated colorspace conversion found
[swscaler @ 0x883e3d0]SwScaler: using unscaled yuv420p -> rgb24 special 
converter

then with pdp_rawin i have to send messages:

[tmp/pipe(
[bitmap/rgb/320x240(

then i have to convert back to yuv using:

[pdp_convert image/YCrCb/*]

and thats the only way i can get it to work.

i have tried something like:

[pdp_rawin tmp/pipe bitmap/yuv (or even yv12)/320x240]

with accompanying altered mencoder script with nothing but a static, f'ed up 
image.

i am not complaining too much because i am pretty happy this is just working in 
general... i am just looking to make it a little more efficient and i am a 
little confused over all the yuv/yv12 stuff that is going on and why i have to 
convert to rgb and back to yuv just to get it to work right - with the 
understanding pdp/yuv is the fastest and most efficient.

BTW the piping stuff is really killer! although i have only been able to get it 
to work on linux... osx gives me a wicked big file that continuously increases 
in size as the stream is converted. linux just makes a 0k tmp/pipe that is very 
nice. i guess this is just a mencoder thing on osx obviously.

thanks!
m
  


--- On Sun, 3/1/09, Jaime Oliver  wrote:

> From: Jaime Oliver 
> Subject: Re: [PD] streaming audio and video in Linux
> To: mgr...@syr.edu
> Cc: "ydego...@gmail.com" , "pd-list" , 
> "John Harrison" 
> Date: Sunday, March 1, 2009, 12:50 PM
> Well, I haven't done it myself, I just know you
> can...there is a mencoder
> list: "MEncoder usage discussions"
> ,
> and documentation somewhere.
> 
> best,
> 
> Jaime
> 
> On Sun, Mar 1, 2009 at 8:17 AM, mark edward grimm
>  wrote:
> 
> >
> > yeah i will take a look at this...
> >
> > might you have an example shell script + pd patch for
> piping stream from
> > mencoder to pdp_rawin?
> >
> > i saw this thread but i am not sure if issue ever were
> resolved:
> >
> >
> http://lists.puredata.info/pipermail/pd-list/2008-04/061727.html
> >
> >
> > thanks!
> > m
> >
> >
> >
> > --- On Sat, 2/28/09, Jaime Oliver
>  wrote:
> >
> > > From: Jaime Oliver
> 
> > > Subject: Re: [PD] streaming audio and video in
> Linux
> > > To: mgr...@syr.edu
> > > Cc: "ydego...@gmail.com"
> , "pd-list"
> ,
> > "John Harrison"
> 
> > > Date: Saturday, February 28, 2009, 2:24 AM
> > > MEncoder maybe?
> > >
> > > On Fri, Feb 27, 2009 at 7:50 AM, mark edward
> grimm
> > >  wrote:
> > >
> > > >
> > > > > no, pdp_icedthe~ can receive a stream
> > > >
> > > > ah thats right thanks!
> > > >
> > > > > we will not try to support an
> .asx/proprietary
> > > format,
> > > >
> > > > understandable yeah i want to
> "hijack"
> > > someone else's stream - it just
> > > > happens to be in .asx!!!
> > > >
> > > > i wonder if there is a method for real-time
> > > transcoding? from asx to
> > > > ogg?
> > > >
> > > > 
> > > > mark edward grimm | m.f.a | ed.m
> > > > syracuse u. | vpa foundations | timearts
> > > > adjunct | new media consultant
> > > > megrimm.net | socialmedia.org/GROUP &
> LLC
> > > > mgr...@syr.edu | 315.378.2136
> > > > 
> > > >
> > > >
> > > >
> > > >
> > > > --- On Fri, 2/27/09, ydego...@gmail.com
> > >  wrote:
> > > >
> > > > > From: ydego...@gmail.com
> > > 
> > > > > Subject: Re: [PD] streaming audio and
> video in
> > > Linux
> > > > > To: mgr...@syr.edu
> > > > > Cc: "pd-list"
> ,
> > > "John Harrison" <
> > > > johnharrison...@gmail.com>
> > > > > Date: Friday, February 27, 2009, 10:39
> AM
> > > > > mark edward grimm wrote:
> > > > > > hmmm... yeah sorry for changing
> the subject
> > > on this.
> > > > > >
> > > > > > I was actually wondering the
> opposite of the
> > > original
> > > > > poster, how to get a stream
> 'into' pd
> > > > > >
> > > > > > For example i have access to a
> stream
> > > > >
> (http://someone-elses-website/live12.asx) that is
> > > not my
> > > > > own
> > > > > >
> > > > > > This stream I can open in VLC
> player for
> > > example
> > > > > >
> > > > > > How can I utilize this stream in
> pd?
> > > directly or
> > > > > indirectly (through vlc player?).
> to do
> > > motion tracking
> > > > > on the stream for example.
> > > > > >
> > > > > > the

Re: [PD] httpget: fun with tcpclient and pdstring

2009-03-04 Thread Martin Peach
Hans-Christoph Steiner wrote:
> 
> I made [httpget] for fetching webpages into pd:


That's nice. Now we need some html parsing objects so the pages go into 
the patch and not the pd window. It works well if the received pages are 
loaded into a table. I made tabfind to search a table for a string. 
Tables seem more efficient than lists and less volatile.


Martin


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


Re: [PD] pd and tcp: what to do against crashes?

2009-03-04 Thread Martin Peach
Roman Haefeli wrote:
> On Wed, 2009-03-04 at 00:45 +0100, Roman Haefeli wrote:
>> how do i know, when the [tcpserver] socket is ready to transmit another
>> byte? do i have to nag it every ms with a message? if i go the
>> BYTE-AT-A-TIME route, the interval would even need to be slower, if
>> higher troughput should be achieved. is there any strategy to avoid too
>> much overhead?
>>
> 
> having thought another two minutes about it, i think i can answer my own
> question: i don't need to drip every byte with an interval, but just
> fill the buffer completely in zero logical time, then i wait a few
> miliseconds, then i do it again. depending on the wait time, the
> connection bandwidth and the buffersize, the buffer will be filled again
> before it completely got empty. this way the maximum available bandwidth
> can be exploited, when necessary, without having to penetrate
> [tcpserver] too much with 'buffer still full?' messages.
> 

You could also try setting the buffer size the same as the message 
length for each outgoing message. Then the buffer wouldn't consume 
thousands of bytes before it stopped.


> martin, would you mind implementing similar changes to [tcpclient] as
> well?
> 
> 

I'll do that today if I have time.

Martin


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


Re: [PD] pd and tcp: what to do against crashes?

2009-03-04 Thread Martin Peach
Roman Haefeli wrote:
> On Wed, 2009-03-04 at 08:08 +0900, PSPunch wrote:
> 
>> The earlier sounds like to introduce massive overhead caused by TCP
>> headers, especially when we are speak of sending amounts of data that
>> may flood the socket's "send buffer." In the later case, the OS may 
>> indicate that bytes entered the socket, while they were actually only 
>> buffered while the connection breaks and was never sent.
>>
> 
> if i interprete my observations correctly, this is not a big deal, since
> not every message sent to [tcpserver] will be transmitted in its own tcp
> frame. at least on my box (ubuntu 8.04), they are sent seperately, if
> there is at least a time interval of ~10ms between them. messages sent
> with shorter intervals are concatenated into one frame. 
> said this, i have to add, that the above is only true, if the number of
> elements of a lists on the receiving side represent the framesize. for
> instance, when i plug out the ethernet cable and fill the buffer on the
> sender side, then plug the cable back in, i get one big list with ~5000
> elements on the receiving side (don't try to print that one, it will
> hang pd)

TCP is supposed to use the Nagle algorithm, which sends the first byte 
as soon as it is put into the buffer, then sends everything in its 
buffer whenever the other end acknowledges the previous message. That's 
the most efficient way to use packets with things like telnet, where 
someone is typing live at the keyboard.
The OS takes care of this and there is no way to control it except to 
switch it off and have every byte sent immediately.

Martin

















> 
> roman
> 
> 
> 
>   
>   
> ___ 
> Der fr?he Vogel f?ngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: 
> http://mail.yahoo.de
> 
> 
> 
> 
> 
> 
> ___
> 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] list issue

2009-03-04 Thread YOhannes
Frank Barknecht schrieb:
> Hallo,
> YOhannes hat gesagt: // YOhannes wrote:
>
>   
>> ive got some trouble with list handling, maybe somone can give me a hand.
>>
>> i like to group an unnown number of floats in a list. (these floats
>> are the result of different divisors, used all for a fixed value. like 
>> 100/16, 100/32...)
>>
>> what i want to do is to put them randomly into the list as long as the 
>> sum of all items
>> in the list equals the size of the fixed value. this seems to be pretty 
>> difficult...since i use
>> random i cant know what the next float will be.
>> 
>
> I don't know if I understand correctly what you mean, but maybe
> [list-equalize] from the [list]-abs collection can help. It scales all
> elements in a list so that their sum is 1. 
>
> If you add a new element into the list this will change the value of old
> elements in the list of course. 
>
> Ciao
>   
maybe i should explain a bit more... the list is thougt as a sequence in 
(ms)values.
i use the length of a master sequence (ms) and divide it by these values 
( 2, 4, 8, 16, 32).
now my idea was to use random and gate to trigger the different results 
of the division into a new slave
sequence, the list. so the length of it depends on the random values...

thanks.j


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


Re: [PD] Pd seriell printers

2009-03-04 Thread brandt
Hello

yes it is a new one. And now I will check the papers

meanwhile thanks
markus






> On Wed, 4 Mar 2009, bra...@subnet.at wrote:
>
>> Hello and thank you
>> [...]
>
> it would be better to keep the discussion on the pd-list.
>
> I know nothing about this printer in particular, but if it's a new machine
> with a RS232 port, I suspect that it's because of systems that still use
> the old Epson protocol:
>
>http://en.wikipedia.org/wiki/ESC/P
>
> See the external links for the manuals for it. This should make you able
> to make your own drivers as pd patches, for whichever features of the
> printer you want to use.
>
>   _ _ __ ___ _  _ _ ...
> | 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] list issue

2009-03-04 Thread Frank Barknecht
Hallo,
YOhannes hat gesagt: // YOhannes wrote:

> ive got some trouble with list handling, maybe somone can give me a hand.
> 
> i like to group an unnown number of floats in a list. (these floats
> are the result of different divisors, used all for a fixed value. like 
> 100/16, 100/32...)
> 
> what i want to do is to put them randomly into the list as long as the 
> sum of all items
> in the list equals the size of the fixed value. this seems to be pretty 
> difficult...since i use
> random i cant know what the next float will be.

I don't know if I understand correctly what you mean, but maybe
[list-equalize] from the [list]-abs collection can help. It scales all
elements in a list so that their sum is 1. 

If you add a new element into the list this will change the value of old
elements in the list of course. 

Ciao
-- 
Frank

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


[PD] list issue

2009-03-04 Thread YOhannes
hello,

ive got some trouble with list handling, maybe somone can give me a hand.

i like to group an unnown number of floats in a list. (these floats
are the result of different divisors, used all for a fixed value. like 
100/16, 100/32...)

what i want to do is to put them randomly into the list as long as the 
sum of all items
in the list equals the size of the fixed value. this seems to be pretty 
difficult...since i use
random i cant know what the next float will be.

how to handle that?
any experience with that issue ?

thanks,
johannes

 


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


Re: [PD] evaluate 3d iterative structures

2009-03-04 Thread simeon cosik
hello, thanks for the reply, are you telling me to take off all the
positions of all the geos and then evaluate in other program?

what about gem_listinfo? i could take of all the positions an save them
in a text file? and  which other software should i use to make this
calculations?
I just checked there is a Ode version that run in pd , called pyode, i
think ode works fine for rigid body simulations, do you think this is a
good option in pd?

On Tue, 3 Mar 2009 10:01:03 -0500 (EST), "Mathieu Bouchard"
 said:
> On Tue, 3 Mar 2009, simeon cosik wrote:
> 
> > Hello, how can i evaluate 3d structures generated in puredata to know if 
> > it can support itself if i build it in reality? for example imagine that 
> > each structure is conformed by a group of boxes one over the others made 
> > with "repeat",i would like to add gravity and weight to all the boxes so 
> > i can i calculate the threshold that i need to maintain in order to 
> > avoid the collapse of my structure. Is this can be done with pmpd? Any 
> > idea?
> 
> You would need to remake your patch to also work without GEM, or find a 
> way to download the geos from GEM.
> 
> One way to make such a "dual-output" patch, is to make it as an 
> abstraction, taking an argument that selects the library it is going to 
> use. suppose your patch is called mymodel.pd:
> 
> [mymodel]would use GEM
> [mymodel gemdump/]   would use a library called gemdump/
> 
> Then within that patch, you would prefix every geo and every geo 
> transformation by $1, such as [$1rotateXYZ]. After that you'd have to
> make 
> a somewhat complex abstraction library that could dump all the 
> coordinates.
> 
> Actually, this pattern (of switching libraries) is very useful, but in 
> this case, it may be too hard, so if I were you, I'd first look for 
> something that can download the geos from the video card, and if I don't 
> find any, I'd make that GEM emulation library that would give me all 
> vertices and edges.
> 
>   _ _ __ ___ _  _ _ ...
> | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
-- 
  simeon cosik
  simeon_co...@fastmail.fm

-- 
http://www.fastmail.fm - Faster than the air-speed velocity of an
  unladen european swallow


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