[PD] [Fwd: Re: Pd-extended on AMD 64]

[ydego...@gmail.com]

--- Begin Message ---

hi,

check that out :
http://giss.tv/wiki/index.php/G.I.S.S._streaming_packages_for_Ubuntu_Hardy

it has pdp opencv already there,
and is available for 64 bits hardy,
what you look for?

to people using already intrepid,
i must say they should use next release : suicidal...

xiaoo
sevy

Loic Kessous wrote:

Hi all,

I try to setup a computer that I got from someone to work with Pd- 
extended on linux (I want to work with video openCV , pdp , etc... and  
to develop some new openCV stuff with it).


I just installed on it Ubuntu hardy 8.04.2 64 bits versions, and I  
hoped to be able to install the version compiled for Ubuntu hardy  
available on the website puredata.info, but the package installer say:


STATUS:ERROR: WRONG ARCHITECTURE 'I386'

I checked on the mailing list archive and I see that there was some   
messages in 2006 reporting problems for this processor with tabread  
tabwrite and other.


So I have three questions:

1) Is there a version already compiled for AMD 64 or should I try to  
compiled it myself (and is it possible?)


2) If I compile it myself, will there be some externals that may not  
work?


3) is it maybe a very bad idea to try to work with this AMD 64  
computer ?


thanks,

loic
---







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

  



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

Re: [PD] Pd-extended on AMD 64

[Ilias Anagnostopoulos]

Hello,

This is an interesting one:
> Date: Thu, 12 Feb 2009 16:27:11 -0500
> From: Hans-Christoph Steiner 
> Subject: Re: [PD] Pd-extended on AMD 64
> To: Loic Kessous 
> Cc: pd-list@iem.at
> Message-ID: <8c05ab00-4468-49ee-9422-230375968...@eds.org>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>
>
> On Feb 12, 2009, at 3:15 PM, Loic Kessous wrote:
>
>   
>>
>> 1) Is there a version already compiled for AMD 64 or should I try to
>> compiled it myself (and is it possible?)
>> 
>
> Build it yourself, there currently aren't any official 64-bit binaries  
> because there is no 64-bit machine in the build farm.  If someone  
> would either donate a 64-bit machine or figure out how to host a 64- 
> bit build on a 32-bit machine, then we could add official 64-bit builds.
>
>   
I have not personally created a good enough binary on amd64 yet, and I 
have been caught up with too many other things since the new year and 
the move of the amd64 machine I was working on.

Has anyone got a 64-bit binary ready that would be good enough as a 
64-bit release (John Harisson was hosting one)? Hosting it couldn't be 
easier: Reprepro will automatically figure out the architecture (if the 
deb is done properly) and will put it in the right place.

You can have access to the repo from a 32-bit machine:

In the /etc/apt/sources.list

deb http://something - stands for the standard architecture

deb-src http://something - stands for the source ARCHITECTURE, since 
source is considered a different architecture in DEB repositories.

deb-amd64 http://something - amd64 architecture on i386 machines

deb-i386 http://something - i386 on amd64 machines.

This is especially useful with apt-mirror for mirroring repos.

If by "hosting" you mean hosting the nightly build or so, how about 
target architecture? Building for amd64 on an i386 by getting all the 
necessary amd64 libs?

I thought the only problem was that some things didn't work yet on 
amd64, not the actual hosting.

-Ilias



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

Re: [PD] locales for Pd WAS: japanese encoded chars in PD

[Hans-Christoph Steiner]

On Thu, 12 Feb 2009, Bryan Jurish wrote:


morning all,

On 2009-02-12 20:22:22, Hans-Christoph Steiner  appears to
have written:

On 2009-02-12 06:24:44, Hans-Christoph Steiner  appears to
have written:

On Feb 11, 2009, at 6:34 AM, Bryan Jurish wrote:

for me, pd *does* display utf-8
strings correctly in message boxes (tested with umlauts äöü, as well as
Greek πδ


Hmm, I am not sure that UTF-8 really is well supported.  Some chars get
thru, but many don't.  Here's an example.  I typed these chars in a
UTF-8 text editor as an png and a pd patch.  Not quite the same.


... I'm not really sure what (if anything) we can conclude from this.
Maybe the text editor is making UTF-8 out of the keyboard input?  The Pd
patch itself is most cetainly not UTF-8 encoded, which makes me suspect
that either (a) Pd is dropping non-printing shift bytes (IOhannes has
pointed out similar goofiness in t_binbuf, but I thought it was only
restricted to NUL bytes) or (b) Tk isn't receiving UTF-8 character codes
at all (whether this is Tk's fault or a system configuration issue is
another question).  At least the latter should be testable with a few
quick wish hacks...


Pd does seem to measure the bytes of the string, measuring the UTF-8
shift bytes as chars.  For exmaple, in barf-both.pd, the message box of
the utf-8 example is much longer than the text inside, while with the
latin1, it is the correct size.


yup.


I don't know if you have followed Pd-devel 0.41.4 at all, but I have
gotten to the point where the GUI is 100% Tcl/Tk so playing with this
stuff should be a lot easier.  Check out the branch, if you would like
to try things.


soon.


Setting LC_CTYPE=en_US.UTF-8 and re-loading "unibarf.pd" got me an odd
error message from Pd though:

Pd: buffer space wasn't sufficient for long GUI string
(repeated 3 times)


I am guessing that the above error comes from the fact that Pd is
written for latin1 where every char is always 1 byte, so sending UTF-8
could confuse things, since UTF-8 can have multi-byte chars.


Kinda; but why is it only the presence of *latin-1* message boxes that
cause complaints about "long GUI strings" (try deleting the utf-8
message box & reloading: the error disappears).  I think an error is
certainly justified in this case (we're feeding a latin-1 encoded
message box to a Pd using a UTF-8 locale); I was just surprised by the
form the error took ;-)


I think that Tcl/Tk tries to guess the locale of the data coming in from
the network socket, then translate it to UTF-8 and back.  Some of the
weirdness we are seeing could be related to that.  In Pd-devel, its much
clearer, so it would be straightforward to play with this encoding
translation stuff, and perhaps turn it off.  Ideally we could have UTF-8
coming from Pd so that Tk doesn't need to do any translation.  That
could speed up things like array/graph redrawing.


Are we certain that Tk is actually translating at all, and not just
using some 8-bit default like latin-1 when it finds non-UTF-8 input?  I
ask because that's what Perl does by default, a behavior which continues
to give me headaches.  In Perl, each string has its own internal "utf8"
flag which tells you whether Perl is currently thinking of that string
as a raw byte-string in some unknown encoding or as a "native" (utf8)
character string... I assume Tcl/Tk does something similar, but don't
know how to test for this property there.


Here's the doc that I read on this topic, but it probably doesn't have the 
lvel of detail that you require:


http://tcl.tk/man/tcl8.5/TclCmd/fconfigure.htm#M8

As for Tk hacking for Pd, a big part of the pd-devel effort is to make the 
Tk GUI code readable, and even extendable!  Feel free to hit me with 
questions, either here, or I am in #dataflow quite a bit these days.


.hc





I don't know for sure, but I suspect one problem might be in the
interpretation of user input


I don't know about the pd side, but Tcl/Tk is all UTF-8 natively, so
that is no problem.


Hmm... not sure what you mean by "natively" here... I mean, Perl uses
UTF-8 as its "native" string encoding, but you can still manipulate byte
strings, read & write files etc in other encodings too.


Yes, same idea.  Internally, Tcl/Tk is using UTF-8, but it can freely
translate between other encodings.


see above.


If we're
talking about user input and the Pd GUI, I think the main issue is how
keyboard input is captured by Tk and passed on to Pd.  If the keyboard
input is being grabbed by Tk bind()ing KeyPress events, then maybe we
just need to edit that bind() call... looks like the KeyPress relevant
"%"-substitutions are (from the Tk bind() manpage):

[snip]

... I'm curious enough to try these out now... just have to dust off my
long unused Tcl/Tk skills a bit ;-)


... so if we're lucky, we can just replace "%k" with "%A" and all will
be good... except for file I/O, which will likely still be done at a raw
byte level.  At this point, all "pure" latin-1 patches will proceed to
break (m

Re: [PD] Phone application

[Hans-Christoph Steiner]

FYI: Reware is just packaging up of PDa.  PDa also works well on the  
older N770.

.hc

On Feb 12, 2009, at 11:58 AM, Nils wrote:

> Hello
>   There is also PDA http://gige.xdv.org/pda/
>   It works great on a nokia n800 running the new diablo OS2008.
>
> Nils
>
> josue moreno wrote:
>> Hi there,
>>
>> is there a way to create a pd patch and make it works in a phone? It
>> doesnt have to be a playable patch, just a generative patch which
>> starts when open that can be used in any regular telephone.
>> I found pd2j2me but that project is not maintained since 2005 and I
>> guess there must be something newer.
>>
>> The idea is to give it as a present to friends, so it doesnt have to
>> be difficult to install in a phone, like a Nokia N73 for instance
>>
>> Thank you,
>>
>> Josué
>>
>>
>> 
>> Actualízate, descubre el nuevo Windows Live Messenger. ¡Descárgatelo
>> ya! 
>> 
>>
>> ___
>> 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





"[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] Pd-extended on AMD 64

[Hans-Christoph Steiner]

On Feb 12, 2009, at 3:15 PM, Loic Kessous wrote:

> Hi all,
>
> I try to setup a computer that I got from someone to work with Pd-
> extended on linux (I want to work with video openCV , pdp , etc... and
> to develop some new openCV stuff with it).
>
> I just installed on it Ubuntu hardy 8.04.2 64 bits versions, and I
> hoped to be able to install the version compiled for Ubuntu hardy
> available on the website puredata.info, but the package installer say:
>
> STATUS:ERROR: WRONG ARCHITECTURE 'I386'
>
> I checked on the mailing list archive and I see that there was some
> messages in 2006 reporting problems for this processor with tabread
> tabwrite and other.
>
> So I have three questions:
>
> 1) Is there a version already compiled for AMD 64 or should I try to
> compiled it myself (and is it possible?)

Build it yourself, there currently aren't any official 64-bit binaries  
because there is no 64-bit machine in the build farm.  If someone  
would either donate a 64-bit machine or figure out how to host a 64- 
bit build on a 32-bit machine, then we could add official 64-bit builds.

> 2) If I compile it myself, will there be some externals that may not
> work?

Yes, check the archives to see which.  Most do work fine though, its  
just a few that don't/

> 3) is it maybe a very bad idea to try to work with this AMD 64
> computer ?

No, its good idea, many people are doing it.

.hc

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







"Free software means you control what your computer does. Non-free  
software means someone else controls that, and to some extent controls  
you." - Richard M. Stallman



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

Re: [PD] video bluescreen

[Max]

maybe you want to check this out:
http://damm-net.org/wiki/index.php?title=Bewegungsmelder
it contains some examples in gem for beginners to get them started.
focus of the patches is to be very basic and simple to make it quickly  
understandable yet giving the students ideas on what is possible to  
spark their own ideas.


any comments appreciated.
feel free to use, recycle, change it.


Am 11.02.2009 um 22:12 schrieb Garrett Lynch:



On 11 Feb 2009, at 13:19, mark edward grimm wrote:

hey if you get it optimized can you send me the result? my time is  
really limited lately but i would love to give a demo to my class  
this semester with your results. i still have not tried it on our  
own green screen yet for lack of time...


Will do, I'm preparing it for a class as well so it will be a fairly  
paired down version but my class is next Monday so not sure I'll get  
it done - anyway I'll forward it on if I do.  Many thanks.


a+
gar

_
garr...@asquare.org
http://www.asquare.org/
http://www.asquare.org/networkresearch/

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




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] Pd-extended on AMD 64

[Loic Kessous]

Hi all,

I try to setup a computer that I got from someone to work with Pd- 
extended on linux (I want to work with video openCV , pdp , etc... and  
to develop some new openCV stuff with it).

I just installed on it Ubuntu hardy 8.04.2 64 bits versions, and I  
hoped to be able to install the version compiled for Ubuntu hardy  
available on the website puredata.info, but the package installer say:

STATUS:ERROR: WRONG ARCHITECTURE 'I386'

I checked on the mailing list archive and I see that there was some   
messages in 2006 reporting problems for this processor with tabread  
tabwrite and other.

So I have three questions:

1) Is there a version already compiled for AMD 64 or should I try to  
compiled it myself (and is it possible?)

2) If I compile it myself, will there be some externals that may not  
work?

3) is it maybe a very bad idea to try to work with this AMD 64  
computer ?

thanks,

loic
---







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

Re: [PD] locales for Pd WAS: japanese encoded chars in PD

[Hans-Christoph Steiner]

On Feb 12, 2009, at 4:40 AM, Bryan Jurish wrote:

> moin Hans, moin all,
>
> On 2009-02-12 06:24:44, Hans-Christoph Steiner   
> appears to
> have written:
>> On Feb 11, 2009, at 6:34 AM, Bryan Jurish wrote:
>>> for me, pd *does* display utf-8
>>> strings correctly in message boxes (tested with umlauts äöü, as  
>>> well as
>>> Greek πδ
>>
>> Hmm, I am not sure that UTF-8 really is well supported.  Some chars  
>> get
>> thru, but many don't.  Here's an example.  I typed these chars in a
>> UTF-8 text editor as an png and a pd patch.  Not quite the same.
>
> ... I'm not really sure what (if anything) we can conclude from this.
> Maybe the text editor is making UTF-8 out of the keyboard input?   
> The Pd
> patch itself is most cetainly not UTF-8 encoded, which makes me  
> suspect
> that either (a) Pd is dropping non-printing shift bytes (IOhannes has
> pointed out similar goofiness in t_binbuf, but I thought it was only
> restricted to NUL bytes) or (b) Tk isn't receiving UTF-8 character  
> codes
> at all (whether this is Tk's fault or a system configuration issue is
> another question).  At least the latter should be testable with a few
> quick wish hacks...

Pd does seem to measure the bytes of the string, measuring the UTF-8  
shift bytes as chars.  For exmaple, in barf-both.pd, the message box  
of the utf-8 example is much longer than the text inside, while with  
the latin1, it is the correct size.

I don't know if you have followed Pd-devel 0.41.4 at all, but I have  
gotten to the point where the GUI is 100% Tcl/Tk so playing with this  
stuff should be a lot easier.  Check out the branch, if you would like  
to try things.

>>> Setting LC_CTYPE=en_US.UTF-8 and re-loading "unibarf.pd" got me an  
>>> odd
>>> error message from Pd though:
>>>
>>> Pd: buffer space wasn't sufficient for long GUI string
>>> (repeated 3 times)
>>
>> I am guessing that the above error comes from the fact that Pd is
>> written for latin1 where every char is always 1 byte, so sending  
>> UTF-8
>> could confuse things, since UTF-8 can have multi-byte chars.
>
> Kinda; but why is it only the presence of *latin-1* message boxes that
> cause complaints about "long GUI strings" (try deleting the utf-8
> message box & reloading: the error disappears).  I think an error is
> certainly justified in this case (we're feeding a latin-1 encoded
> message box to a Pd using a UTF-8 locale); I was just surprised by the
> form the error took ;-)

I think that Tcl/Tk tries to guess the locale of the data coming in  
from the network socket, then translate it to UTF-8 and back.  Some of  
the weirdness we are seeing could be related to that.  In Pd-devel,  
its much clearer, so it would be straightforward to play with this  
encoding translation stuff, and perhaps turn it off.  Ideally we could  
have UTF-8 coming from Pd so that Tk doesn't need to do any  
translation.  That could speed up things like array/graph redrawing.

>>> I don't know for sure, but I suspect one problem might be in the
>>> interpretation of user input
>>
>> I don't know about the pd side, but Tcl/Tk is all UTF-8 natively, so
>> that is no problem.
>
> Hmm... not sure what you mean by "natively" here... I mean, Perl uses
> UTF-8 as its "native" string encoding, but you can still manipulate  
> byte
> strings, read & write files etc in other encodings too.

Yes, same idea.  Internally, Tcl/Tk is using UTF-8, but it can freely  
translate between other encodings.

> If we're
> talking about user input and the Pd GUI, I think the main issue is how
> keyboard input is captured by Tk and passed on to Pd.  If the keyboard
> input is being grabbed by Tk bind()ing KeyPress events, then maybe we
> just need to edit that bind() call... looks like the KeyPress relevant
> "%"-substitutions are (from the Tk bind() manpage):
>
> %k - The keycode field from the event. Valid only for KeyPress and
> KeyRelease events.
>
> %A - Substitutes the UNICODE character corresponding to the event, or
> the empty string if the event does not correspond to a UNICODE  
> character
> (e.g. the shift key was pressed). XmbLookupString (or XLookupString  
> when
> input method support is turned off) does all the work of translating
> from the event to a UNICODE character. Valid only for KeyPress and
> KeyRelease events.
>
> %K - The keysym corresponding to the event, substituted as a textual
> string. Valid only for KeyPress and KeyRelease events.
>
> %N - The keysym corresponding to the event, substituted as a decimal
> number. Valid only for KeyPress and KeyRelease events.
>
> ... so if we're lucky, we can just replace "%k" with "%A" and all will
> be good... except for file I/O, which will likely still be done at a  
> raw
> byte level.  At this point, all "pure" latin-1 patches will proceed to
> break (maybe just display problems, maybe more serious).  If we say
> we're going whole-hog utf-8, we can say that it's the user's problem  
> to
> recode any such files (e.g. with iconv or recode; I'

Re: [PD] Phone application

[josue moreno]

What I found is the paper introducing the 
system:http://ro.uow.edu.au/cgi/viewcontent.cgi?article=1020&context=creartspapersj2me
 is still around, so maybe is not so hard to implement something similar to 
pd2j2me.Anyway, the main problem here is that I want it to work in phones that 
dont have touchscreen or anything like that.Cheers> CC: pd-list@iem.at> From: 
st...@dibidut.dk> Subject: Re: [PD] Phone application> Date: Thu, 12 Feb 2009 
19:45:57 +0100> To: josuemore...@hotmail.com> > > On 12/02/2009, at 12.58, 
josue moreno wrote:> >> I found pd2j2me (snip)> > Did you find the actual 
"compiler" or the source? I can't seam to  > locate any of it, that's why i 
ask.> > Best wishes. 
_
Consigue gratis el nuevo Messenger. ¡Descárgatelo! 
http://download.live.com/___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Phone application

[Steffen Juul]

On 12/02/2009, at 12.58, josue moreno wrote:

> I found pd2j2me (snip)

Did you find the actual "compiler" or the source? I can't seam to  
locate any of it, that's why i ask.

Best wishes. 

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

Re: [PD] Phone application

[Nils]

Hello
   There is also PDA http://gige.xdv.org/pda/
   It works great on a nokia n800 running the new diablo OS2008.

Nils

josue moreno wrote:
> Hi there,
>
> is there a way to create a pd patch and make it works in a phone? It 
> doesnt have to be a playable patch, just a generative patch which 
> starts when open that can be used in any regular telephone.
> I found pd2j2me but that project is not maintained since 2005 and I 
> guess there must be something newer.
>
> The idea is to give it as a present to friends, so it doesnt have to 
> be difficult to install in a phone, like a Nokia N73 for instance
>
> Thank you,
>
> Josué
>
>
> 
> Actualízate, descubre el nuevo Windows Live Messenger. ¡Descárgatelo 
> ya! 
> 
>
> ___
> 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] MIDI on OSX

[Luigi]

Hi there

I would like to mention a hint that helped myself some time ago

have a look at "midifile", which is part of mrpeach externals...

Which does not play midi-sounds but midifilesto be exact.

Do you just want to play midisounds ? or generate midinotes, maybe ??

And of course there is the wonderful object "mtof" that converts midi- 
notes to frequnecies and thus
you can play midifiles or midinotes with any selfmade oscillator/ 
synthesizer

I had a lot of fun playing with midifiles and

"polywavesynth" for example


Cheers Luigi


Am 10.02.2009 um 20:19 schrieb Max:

> there is a wrapper application which lets you use the general midi  
> instruments in quicktime
>
> http://notahat.com/simplesynth/
>
> it's only 204 KB big. this is the simplest solution afaik.
>
>
> Am 10.02.2009 um 19:45 schrieb enrique franco:
>
>> Hi,
>>
>> How can I play MIDI sounds from PD in OSX? It is necessary to have  
>> another MIDI software running? Can I just play General MIDI from PD?
>>
>> Cheers,
>>
>> -- 
>> Enrique Franco
>> Telefono/Phone: +572 5552334 ext 388
>> Webpage: http://richie.idc.ul.ie/~enrique/
>> http://www.iua.upf.es/~ffranco/pfm.htm
>> ___
>> 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] Phone application

[Nicholas Mariette]

Have a look at RjDj - which is essentially Pd for iPhone.
The coming beta release allows downloading new Pd patches ("scenes")  
onto an iPhone.
http://www.rjdj.me/

or there's the Reware project:
http://dev.eyebeam.org/projects/reware/blog

from a Pd list mail from Hans-Christoph Steiner:
> I don't know if you have been following the Reware project, but that
> is a core idea of it.  Check out our first HOWTO for an intro:
>
> http://www.youtube.com/watch?v=tMnIh2lWB6M

Nick


On Feb 12, 2009, at 12:58 PM, josue moreno wrote:

> Hi there,
>
> is there a way to create a pd patch and make it works in a phone? It  
> doesnt have to be a playable patch, just a generative patch which  
> starts when open that can be used in any regular telephone.
> I found pd2j2me but that project is not maintained since 2005 and I  
> guess there must be something newer.
>
> The idea is to give it as a present to friends, so it doesnt have to  
> be difficult to install in a phone, like a Nokia N73 for instance
>
> Thank you,
>
> Josué
>
>
> Actualízate, descubre el nuevo Windows Live Messenger. ¡Descárgatelo  
> ya! ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list

Nicholas Mariette

Researcher
Audio and Acoustics group
LIMSI-CNRS, Orsay, France
http://www.limsi.fr/Scientifique/aa/
http://www.limsi.fr/Scientifique/ps/thmsonesp/SonEspace
http://soundsorange.net
nicholas.marie...@limsi.fr





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

[PD] CORRECTION: Pure Data Basics: a Project-Oriented Workshop with Derek Holzer

[Derek Holzer]

CORRECTION: registration address in previous email was incorrect. 
Correct address below!

Pure Data Basics: a Project-Oriented Workshop with Derek Holzer

Wednesday 11 March - Sunday 15 March 2009
11.00-19.00 daily with one hour lunch break
Final presentation Sunday 15 March, 19.00

Location: eNKa /  ElsenStr. 52 (2.Hof) Berlin, Germany
Telephone: +49 (0)176 20626386

Course Participation fee: 100 euros
Registration is required for this workshop and can only be done via
email to: enka...@gmx.de
Please register early to ensure a place. Places are limited to 12.
Participants should indicate ahead of time what their background and
areas of interest are (sound, video, sensors, etc) as well as give a
short description of any project they might want to develop during the
workshop.


Pure Data is a powerful, free and open-source software environment for
producing and manipulating sound, image, data and connections to
sensors, motors and other "physical computing" functions, all in real
time. Because the programming is done visually, many artists find it a
more intuitive tool than traditional text-oriented programming
languages. This 5 day workshop will cover the basic "grammar" and
"vocabulary" of the Pure Data language through a mix of lecture and
demonstration in the mornings and project-based mentoring in the
afternoons. This workshop is open to those with no previous computer
programming experience, however basic computer literacy is assumed as
well as a working familiarity with either digital audio or video. A
manual-in-progress for Pure Data by Derek Holzer can be found here:

http://flossmanuals.net/puredata

5 DAY CURRICULUM

DAY ONE:
1) Meeting PD: the interface and how to play with it
2) Basic PD: participants learn to make a simple synthesizer, and
learn basic PD grammar in the process
3) Workshop: discussions of examples and work on student projects

DAY TWO:
1) PD audio: more on oscillators, noise, delays, feedback, filters and
signal analysis for all your sonic needs
2) Events in PD: participants explore the timing of events with
sequencers, delays, messages
3) Workshop: discussions of examples and work on student projects

DAY THREE:
1) Working with soundfiles: loading audio for use in samplers,
granulators and other file-based sound manipulation systems
2) Basic GEM: how to create simple 3D objects, play videos and get
camera input
3) Workshop: discussions of examples and work on student projects

DAY FOUR:
1) Physical PD: an introduction to physical computing using Pure Data
alongside a microcontroller-based board such as the Arduino or
xAVR/HID--or even a hacked USB gamepad--to work with sensors,
motors, lights, etc.
2) Workshop: discussions of examples and work on student projects

DAY FIVE:
1) Workshop: discussions of examples and work on student projects
2) The Wrap Up: public presentation of student works + closing party.

WHAT PARTICIPANTS SHOULD BRING

Essential:

1) Laptop running Linux, OS X or Windows
2) Pure Data Extended installed from: http://puredata.info/downloads
(please make sure it is Extended package!)
3) Soundcard
4) Headphones

Recommended/Suggested:

1) MIDI controller/keyboard
2) Microphone/piezoelectric contact microphone
3) USB Joystick/Gamepad
4) Sensors or other input devices (please bring your own sensors if
you are interested in working with them, as only a few light sensors
will be provided at the workshop)
5) Small motors or motor-driven objects
6) USB webcam/Firewire camera
7) Arduino boards (Available from Segor in Berlin: www.segor.de)
and/or the xAVR/HID board (http://www.1010.co.uk/avrhid.html,
please inquire via the x webpage about preordering!)
8) Your own projects and ideas to realize!

ABOUT THE INSTRUCTOR

BIOGRAPHY
Derek Holzer [USA 1972] is a sound artist with a background in radio,
webstreaming and environmental recording. His work focuses on
capturing and transforming small, unnoticed sounds from various
natural and urban locations, networked collaboration strategies,
experiments in improvisational sound and the use of free software such
as Pure-Data. He has released tracks under the Nexsound, Sirr,
and/OAR, Frozen Elephants Music, Mandorla and Gruenrekorder labels,
and has co-initiated several internet projects for field recording and
collaborative soundscapes including Soundtransit.nl. His recent
projects include the opto-electronic audiovisual performance
TONEWHEELS, solo performances for analog synthesizer and a manual for
Pure Data. He was also co-curator of the Tuned City event for sound
and architecture, which took place in Berlin during July 2008.

http://umatic.nl/info_derek.html
http://www.myspace.com/macumbista



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

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



__

[PD] [PD-announce] CORRECTION: Pure Data Basics: a Project-Oriented Workshop with Derek Holzer

[Derek Holzer]

Pure Data Basics: a Project-Oriented Workshop with Derek Holzer

Wednesday 11 March - Sunday 15 March 2009
11.00-19.00 daily with one hour lunch break
Final presentation Sunday 15 March, 19.00

Location: eNKa /  ElsenStr. 52 (2.Hof) Berlin, Germany
Telephone: +49 (0)176 20626386

Course Participation fee: 100 euros
Registration is required for this workshop and can only be done via
email to: enka...@gmx.de
Please register early to ensure a place. Places are limited to 12.
Participants should indicate ahead of time what their background and
areas of interest are (sound, video, sensors, etc) as well as give a
short description of any project they might want to develop during the
workshop.


Pure Data is a powerful, free and open-source software environment for
producing and manipulating sound, image, data and connections to
sensors, motors and other "physical computing" functions, all in real
time. Because the programming is done visually, many artists find it a
more intuitive tool than traditional text-oriented programming
languages. This 5 day workshop will cover the basic "grammar" and
"vocabulary" of the Pure Data language through a mix of lecture and
demonstration in the mornings and project-based mentoring in the
afternoons. This workshop is open to those with no previous computer
programming experience, however basic computer literacy is assumed as
well as a working familiarity with either digital audio or video. A
manual-in-progress for Pure Data by Derek Holzer can be found here:

http://flossmanuals.net/puredata

5 DAY CURRICULUM

DAY ONE:
1) Meeting PD: the interface and how to play with it
2) Basic PD: participants learn to make a simple synthesizer, and
learn basic PD grammar in the process
3) Workshop: discussions of examples and work on student projects

DAY TWO:
1) PD audio: more on oscillators, noise, delays, feedback, filters and
signal analysis for all your sonic needs
2) Events in PD: participants explore the timing of events with
sequencers, delays, messages
3) Workshop: discussions of examples and work on student projects

DAY THREE:
1) Working with soundfiles: loading audio for use in samplers,
granulators and other file-based sound manipulation systems
2) Basic GEM: how to create simple 3D objects, play videos and get
camera input
3) Workshop: discussions of examples and work on student projects

DAY FOUR:
1) Physical PD: an introduction to physical computing using Pure Data
alongside a microcontroller-based board such as the Arduino or
xAVR/HID--or even a hacked USB gamepad--to work with sensors,
motors, lights, etc.
2) Workshop: discussions of examples and work on student projects

DAY FIVE:
1) Workshop: discussions of examples and work on student projects
2) The Wrap Up: public presentation of student works + closing party.

WHAT PARTICIPANTS SHOULD BRING

Essential:

1) Laptop running Linux, OS X or Windows
2) Pure Data Extended installed from: http://puredata.info/downloads
(please make sure it is Extended package!)
3) Soundcard
4) Headphones

Recommended/Suggested:

1) MIDI controller/keyboard
2) Microphone/piezoelectric contact microphone
3) USB Joystick/Gamepad
4) Sensors or other input devices (please bring your own sensors if
you are interested in working with them, as only a few light sensors
will be provided at the workshop)
5) Small motors or motor-driven objects
6) USB webcam/Firewire camera
7) Arduino boards (Available from Segor in Berlin: www.segor.de)
and/or the xAVR/HID board (http://www.1010.co.uk/avrhid.html,
please inquire via the x webpage about preordering!)
8) Your own projects and ideas to realize!

ABOUT THE INSTRUCTOR

BIOGRAPHY
Derek Holzer [USA 1972] is a sound artist with a background in radio,
webstreaming and environmental recording. His work focuses on
capturing and transforming small, unnoticed sounds from various
natural and urban locations, networked collaboration strategies,
experiments in improvisational sound and the use of free software such
as Pure-Data. He has released tracks under the Nexsound, Sirr,
and/OAR, Frozen Elephants Music, Mandorla and Gruenrekorder labels,
and has co-initiated several internet projects for field recording and
collaborative soundscapes including Soundtransit.nl. His recent
projects include the opto-electronic audiovisual performance
TONEWHEELS, solo performances for analog synthesizer and a manual for
Pure Data. He was also co-curator of the Tuned City event for sound
and architecture, which took place in Berlin during July 2008.

http://umatic.nl/info_derek.html
http://www.myspace.com/macumbista



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

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


___
Pd-announce mailing list
pd-annou...@iem.at
http://lists.pure

[PD] Phone application

[josue moreno]

Hi there,is there a way to create a pd patch and make it works in a phone? It 
doesnt have to be a playable patch, just a generative patch which starts when 
open that can be used in any regular telephone.I found pd2j2me but that project 
is not maintained since 2005 and I guess there must be something newer.The idea 
is to give it as a present to friends, so it doesnt have to be difficult to 
install in a phone, like a Nokia N73 for instanceThank you,Josué
_
Consigue gratis el nuevo Messenger. ¡Descárgatelo! 
http://download.live.com/___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] string2any in arduino.pd is now broken

[Bryan Jurish]

morning all,

On 2009-02-12 10:42:10, Frank Barknecht  appears to
have written:
> Hallo,
> Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
> 
>> So I have been happily using the string2any object in my arduino  
>> object and it works well.   But it seems that something has changed,  
>> and it now causes a freak out on load:
>>
>> string2any_setup(): WARNING: names are in flux!
>> string2any_setup(): Prefer [bytes2any] over [string2any].
>> bytes2any: pdstring version 0.09 by Bryan Jurish
>> moocow/string2any: already loaded
>> ... snip (repeat 1000 times) ...
>> moocow/string2any: already loaded
>> error: maximum object loading depth 1000 reached
> 
> Isn't this the issue with hexloader reported some time ago? Does it
> fail on vanilla or a pd-extended with no libs loaded as well?

Hmm... I'm not familiar with the hexloader bug you mention.  In trying
to maintain maximal backwards-compatibility, I set up [pdstring] in
single-object-external mode (which pd-extended uses) to install
"any2string.pd_whatever" as a symlink to "any2bytes.pd_whatever".
Additionally, any2bytes.c contains an "any2string_setup()" function as
well as a runtime check to prevent multiple setup() calls.

Is the problem due to the use of a symlink (e.g. does it persist if
moocow/string2any.pd_linux is a copy of moocow/bytes2any.pd_linux?)  Or
is every solution ultimately relying on class_addcreator() doomed to
failure?  I can make [string2any] just an abstraction wrapping
[bytes2any] as well; I just anticipated interference from old
installations with that trick...

marmosets,
Bryan

-- 
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] locales for Pd WAS: japanese encoded chars in PD

[Bryan Jurish]

moin Hans, moin all,

On 2009-02-12 06:24:44, Hans-Christoph Steiner  appears to
have written:
> On Feb 11, 2009, at 6:34 AM, Bryan Jurish wrote:
>> for me, pd *does* display utf-8
>> strings correctly in message boxes (tested with umlauts äöü, as well as
>> Greek πδ
> 
> Hmm, I am not sure that UTF-8 really is well supported.  Some chars get
> thru, but many don't.  Here's an example.  I typed these chars in a
> UTF-8 text editor as an png and a pd patch.  Not quite the same.

... I'm not really sure what (if anything) we can conclude from this.
Maybe the text editor is making UTF-8 out of the keyboard input?  The Pd
patch itself is most cetainly not UTF-8 encoded, which makes me suspect
that either (a) Pd is dropping non-printing shift bytes (IOhannes has
pointed out similar goofiness in t_binbuf, but I thought it was only
restricted to NUL bytes) or (b) Tk isn't receiving UTF-8 character codes
at all (whether this is Tk's fault or a system configuration issue is
another question).  At least the latter should be testable with a few
quick wish hacks...

>> Setting LC_CTYPE=en_US.UTF-8 and re-loading "unibarf.pd" got me an odd
>> error message from Pd though:
>>
>> Pd: buffer space wasn't sufficient for long GUI string
>> (repeated 3 times)
> 
> I am guessing that the above error comes from the fact that Pd is
> written for latin1 where every char is always 1 byte, so sending UTF-8
> could confuse things, since UTF-8 can have multi-byte chars.

Kinda; but why is it only the presence of *latin-1* message boxes that
cause complaints about "long GUI strings" (try deleting the utf-8
message box & reloading: the error disappears).  I think an error is
certainly justified in this case (we're feeding a latin-1 encoded
message box to a Pd using a UTF-8 locale); I was just surprised by the
form the error took ;-)

>> I don't know for sure, but I suspect one problem might be in the
>> interpretation of user input
> 
> I don't know about the pd side, but Tcl/Tk is all UTF-8 natively, so
> that is no problem.

Hmm... not sure what you mean by "natively" here... I mean, Perl uses
UTF-8 as its "native" string encoding, but you can still manipulate byte
strings, read & write files etc in other encodings too.  If we're
talking about user input and the Pd GUI, I think the main issue is how
keyboard input is captured by Tk and passed on to Pd.  If the keyboard
input is being grabbed by Tk bind()ing KeyPress events, then maybe we
just need to edit that bind() call... looks like the KeyPress relevant
"%"-substitutions are (from the Tk bind() manpage):

 %k - The keycode field from the event. Valid only for KeyPress and
KeyRelease events.

 %A - Substitutes the UNICODE character corresponding to the event, or
the empty string if the event does not correspond to a UNICODE character
(e.g. the shift key was pressed). XmbLookupString (or XLookupString when
input method support is turned off) does all the work of translating
from the event to a UNICODE character. Valid only for KeyPress and
KeyRelease events.

 %K - The keysym corresponding to the event, substituted as a textual
string. Valid only for KeyPress and KeyRelease events.

 %N - The keysym corresponding to the event, substituted as a decimal
number. Valid only for KeyPress and KeyRelease events.

... so if we're lucky, we can just replace "%k" with "%A" and all will
be good... except for file I/O, which will likely still be done at a raw
byte level.  At this point, all "pure" latin-1 patches will proceed to
break (maybe just display problems, maybe more serious).  If we say
we're going whole-hog utf-8, we can say that it's the user's problem to
recode any such files (e.g. with iconv or recode; I'm happy to help out
with a few scripts); otherwise we might want to do something paranoid
and try to guess a patch's encoding when it's loaded.  Or we use
locale-dependent functions, but that makes sharing patches harder
between people using different locales.  Or we use the XML-style
solution and just save the encoding to use in the patch header ;-)

>> bash$ export LC_CTYPE=en_DK.UTF-8
>> bash$ pd uselocale.pd barf-both.pd   ##-- latin-1 displays incorrectly
>>
>> bash$ export LC_CTYPE=en_DK.ISO-8859-1
>> bash$ pd uselocale.pd barf-both.pd   ##-- all displays ok
>>
>> If it turns out to work well, we can of course make a trivial "dummy"
>> external out of it for use with "-lib" ...
> 
> Hmm, I tried this on Mac OS X and it didn't seem to make a difference. 
> Perhaps its a platform issue, though on this level, Mac OS X is very
> much BSD, so I think it should work.

The locale strategy also depends on what locales your system has
installed.  Here (linux/debian), I can see which locales are installed with:

   bash$ locale -a

... I would expect goofiness trying to use "en_DK.UTF-8" if it's not
been installed ...

marmosets,
Bryan

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

Re: [PD] string2any in arduino.pd is now broken

[Frank Barknecht]

Hallo,
Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:

> So I have been happily using the string2any object in my arduino  
> object and it works well.   But it seems that something has changed,  
> and it now causes a freak out on load:
> 
> string2any_setup(): WARNING: names are in flux!
> string2any_setup(): Prefer [bytes2any] over [string2any].
> bytes2any: pdstring version 0.09 by Bryan Jurish
> moocow/string2any: already loaded
> ... snip (repeat 1000 times) ...
> moocow/string2any: already loaded
> error: maximum object loading depth 1000 reached

Isn't this the issue with hexloader reported some time ago? Does it
fail on vanilla or a pd-extended with no libs loaded as well?

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