Pd-list February 2002

pd-list@lists.iem.at

89 participants
173 discussions

yves' grid for NT/2K
by joge . 26 Feb '02

26 Feb '02

me again .. this time i am working on getting the grid object ported to windows nt/2k . the problem i am running into now is in the linker . heres what i am getting .. Finished pass 1 grid.obj : error LNK2019: unresolved external symbol __imp__rtext_new_without_senditup referenced in function _grid_vis Debug/grid.dll : fatal error LNK1120: 1 unresolved externals any insight is greatly appreciated . joge . oh by the way .. if any one is interested in this and/or the pianoroll object for nt i can post my compiled ones on the web, though i dont think i will be much help as far as *support* goes.

3 5

Envelopes
by Rodrigo F. Cadiz 26 Feb '02

26 Feb '02

Hi! I wonder what is the best approach to write audio envelopes in Pd... something like the GEN functions or linseg objects in Csound. Or like the line object in Max. As fas as I know, in Max you can specify several pairs of points to line (like a csound's linseg) instead of just one as in Pd. Please correct me if I am wrong. I can think of a metro triggering different line~objects at different times but that does not seem too good for me.... I'll appreciate any ideas. Thanks, +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++ ++++ Rodrigo F. Cadiz ++ ++ rcadiz(a)northwestern.edu ++ ++ http://www.geocities.com/rfcadiz ++ ++ ++ ++ Music Technology Program ++ School of Music ++ ++ Northwestern University ++++ Evanston, IL +++++ USA ++++ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

2 1

multichannel audio & multiport midi
by Sergi Jorda 26 Feb '02

26 Feb '02

Maybe that has been already covered but, Is it currently possible to have multiport midi in the windows version (either in and out)? Is it possible to support multichannel I/O audio cards (in the w.vers also) ? (I want to receive and output separated audio channels) sergi

2 1

beware of scripting
by jfm3 26 Feb '02

26 Feb '02

It would be great to add procedural scripting to Pd. Here are the issues I forsee. 1) Wait until Pd "data structures" solidify. Then integrate this feature into your scripting language. 2) Beware of batch time garbage collectors. They can easily ruin a real time process. Of course, python's gc is not rt, but that doesn't stop Joe from having a great time with GripD (http://mambo.peabody.jhu.edu/~jsarlo/gripd). New pure-data.org "real soon now". -- (jfm3)

1 0

Putting sounds on different channels
by Marcus Flanagan 25 Feb '02

25 Feb '02

2 1

RE: [PD] Scripting
by mark 25 Feb '02

25 Feb '02

Hi, if you have any code I would certainly be interested - I would be using 2.2 I think (might as well start up to date). Python.org seem to keep things upto date pretty well - or are you using a different release?. Good luck with CORBA - I moved our application at work to it recently (from Java RMI). It works well but it can be pretty heavy going. Not sure if I would want to use it with PD unless I was doing a big distributed installation - in which case it would be ideal. cheers mark > -----Original Message----- > From: ludwig zeininger [mailto:lu@mur.at] > Sent: 25 February 2002 15:18 > To: 'Pd-List' > Subject: Re: [PD] Scripting > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > hi > > i had a python external written for an installation i did two years > ago. the reason i never published it was that the author does > not maintain > the package, and i had lost the source (...). but just last > night i found > it on my old notebook - back from 'service' after more than > one year, now > completely broken but for the harddrive, to hell with gericom! > anyway, it works fine, the python thingy, that is... (had it > running in an > installation for 6 consecutive months), is not complete (not > all pd types > are supported), restricted to python1.5 and since the interpreter > runs inside pd it can block. > let me know if you're interested. i can send you the code or > post a link > here. > > and just to wet your appetites: there's a corba external coming up. > > lu > > > On Mon, 25 Feb 2002, mark wrote: > > ::Hi, > :: > ::I gave some serious thought to the scripting thing last > night. I am thinking > ::of building a "python" external that would allow simple > scripts - you > ::would make make an object: > :: > :: py scriptname > :: > ::which would take a python class that is similar in > structure to the external > ::"class" structure used by externals currently - obviously a > bit more simple. > ::No DSP of course (can't imagine it would be vaguely fast > enough). Python > ::is a good fit with PD I belive - it does good list type > manipulation (in > ::fact > ::it will be easy to write a set of list manipulation > externals which I have > ::been > ::wanting for a while now) and its got some quite nifty > features. Oh and I > ::want > ::to learn it which strikes me as a good a reason as any ;-) > :: > ::So - does anyone have any requests for features or things I > should be > ::considering? > :: > ::cheers > :: > ::mark > :: > :: > > > - -- > > >> http://lu.mur.at/lu.pub.key.html << > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.6 (GNU/Linux) > Comment: Made with pgp4pine > > iD8DBQE8elW8ea0RHHXBzw0RAhBYAJ0R3qTMzJx7m34lsPg7jlhjhLjmeACfdy7V > 4GPnqArfARKEPdnlK9r+c8A= > =+WKU > -----END PGP SIGNATURE----- >

1 0

RE: [PD] Scripting
by mark 25 Feb '02

25 Feb '02

> you could start off with .py but later or somebody else > extend to perl, > php4, bash, java-ecmascript, funge98, &c &c ? > This is not so easy in C. In Java you can use the BSF which allows java to expose internal objects to a large number of different langauges. The problem in C is that each of these scripting languages has a different way of exposing C objects. Looking at the python stuff there is no way this would work for other languages. The problem is marshalling data from one language to the other. In order to make this work for all langauges you would end up writing a generic scripting engine which knew how to marhall PD data into each separate languge probably using some sort of intermediate representation- not something I am wanting to do right now (or ever for that matter). The only way I can think to make it available to more languagues is to use COM (windows only) or CORBA (serious serious serious) Making a Java scripting engine would be trivial (well it would to me - I work with Java most of the time at work) and possibly more cross platform and you could then but leap frog into other languages via BSF but you are adding layer upon layer of translation and perfomance will be going rapidly downhill at this point. I also feel that python has more relvant scripting type stuff in it and would be quite interesting in conjunction with PD. mark > -----Original Message----- > From: _-¯-_ [mailto:jdl@xdv.org] > Sent: 25 February 2002 15:08 > To: 'Pd-List' > Subject: Re: [PD] Scripting > > > |> I thought about perl but I have to relearn perl every > time I need to > |> use it - its the only languae I use regularly that I need loads of > |> reference books for > | > |Don't go Perl, go Python! This is of course flamewar stuff (and has > |already provoked one on csound-list), but I can see a > simple reason, why > |Perl is not appropriate as a PD scripting language: It uses the $ to > |declare $variables! Combine that with PD's own use of the > dollar symbol > |and I see a big mess coming. > > the optimum would be something like a generic "script" object with the > first creation argument specifying the interpreter or > autodetection from > file suffix whatever. > > -- X D v · o r 6 > >

1 0

RE: [PD] Scripting
by mark 25 Feb '02

25 Feb '02

I thought about perl but I have to relearn perl every time I need to use it - its the only languae I use regularly that I need loads of reference books for - as a contrast whilst the C programming I am doing for PD is the first C /C++ I have done for nearly 6 years I can still remember a lot of the functions and libraries. mark > -----Original Message----- > From: Frank Barknecht [mailto:barknech@ph-cip.uni-koeln.de] > Sent: 25 February 2002 13:04 > To: 'Pd-List' > Subject: Re: [PD] Scripting > > > mark hat gesagt: // mark wrote: > > > I gave some serious thought to the scripting thing last > night. I am thinking > > of building a "python" external that would allow simple > scripts - you > > would make make an object: > > > > py scriptname > > > > which would take a python class that is similar in > structure to the external > > "class" structure used by externals currently - obviously a > bit more simple. > > No DSP of course (can't imagine it would be vaguely fast enough). > > Python is a good fit with PD I belive - it does good list type > > manipulation (in fact it will be easy to write a set of list > > manipulation externals which I have been wanting for a > while now) and > > its got some quite nifty features. Oh and I want to learn it which > > strikes me as a good a reason as any ;-) > > I like the idea very much. Larry Troxler started something similar > with his PD-Scheme external, maybe you can get some inspiration here > (http://www.westnet.com/~lt/pd/). Python is not that far away from > Scheme in some regards. I would probably prefer Python as a scripting > language, as I know this a lot better than I know Scheme. I > know Perl even > better, but I am always happy *not* having to write in Perl anymore ;) > > bye, > -- > __ __ > Frank Barknecht ____ ______ ____ __ trip\ \ / /wire ______ > / __// __ /__/ __// // __ \ \/ / __ \\ ___\ > / / / ____/ / / / // ____// /\ \\ > ___\\____ \ > /_/ /_____/ /_/ /_//_____// / \ \\_____\\_____\ /_/ \_\

3 2

RE: [PD] Scripting
by mark 25 Feb '02

25 Feb '02

I know nothing about tcl plus I am not overly interested in it. So the main advantage is that I am likely to get round to building the python script object (and have a good idea about how to go about it - there is a fairly straight forward API which allows you to implement python objects in C). So the bottom line is - if you want TCL you will have to do it yourself. Thats not to say its not a good idea BTW mark > -----Original Message----- > From: Ben Bogart - FMPM/F1999 [mailto:bbogart@acs.ryerson.ca] > Sent: 25 February 2002 15:03 > To: mark > Cc: 'Pd-List' > Subject: Re: [PD] Scripting > > > tcl might not work for a lot of needs, but how difficult > would it be to > have a tcl scripting external? Allows some quite complex > operations, fast > array searches and of course easy GUI creation. I currently > have a tcl > script that writes an array of 100+ gem objects, it would be > neat to have > this script exist inside a "script" object. > > whats the advantage of python of tcl? since the interpreter > is already > there... > > Ben > > > > On Mon, 25 Feb 2002, mark wrote: > > > Hi, > > > > I gave some serious thought to the scripting thing last > night. I am thinking > > of building a "python" external that would allow simple > scripts - you > > would make make an object: > > > > py scriptname > > > > which would take a python class that is similar in > structure to the external > > "class" structure used by externals currently - obviously a > bit more simple. > > No DSP of course (can't imagine it would be vaguely fast > enough). Python > > is a good fit with PD I belive - it does good list type > manipulation (in > > fact > > it will be easy to write a set of list manipulation > externals which I have > > been > > wanting for a while now) and its got some quite nifty > features. Oh and I > > want > > to learn it which strikes me as a good a reason as any ;-) > > > > So - does anyone have any requests for features or things I > should be > > considering? > > > > cheers > > > > mark > > > > > > > > > > B. Bogart > --------- >

1 0

pianoroll on nt .
by joge . 25 Feb '02

25 Feb '02

hi , i just got the pianoroll.dll compiled on my machine [i used the workspace from idelay~ and modifed the dependences and some names]. any how , now i try to load it into pd [both 34 and 35] and i says it can't find the "pianoroll_setup" symbol . here is the exact message : load_object: Symbol "pianoroll_setup" not found pianoroll: can't load library anybody know what this might be. i read some earlier posts that the code itself should work fine on both linux and windows, only the compilation is different. oh yeah.. and to get it to compile using the pd 34 libraries i had to change one of the variable names that seems to have changed in pd 35. i got idelay~ compiled and running fine on my machine so i am not sure what the problem could be . any help would be greatly appreciated . joge .

3 4

← Newer
1
2
3
4
5
6
7
...
18
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Pd-list February 2002