Hi,
I'm new to PD and I'm about to embark on a project to design a multi-timbral additive synth.
In the final implementation I would like to have an XY controller to control relative partial weightings (a tristimulus technique).
Any help on basic implementation or approaches would be greatly appreciated.
Also need advice on: i)Basic additive synthesis in PD i.e. if anyone has a very basic additive synth patch, I would like to see it.
ii)How to create a smart GUI
iii)Converting a PD project to a VSTi
Thanks, Al
Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://mail.messenger.yahoo.co.uk
Al,
Quoting Al Riley alrileyuk@yahoo.co.uk:
In the final implementation I would like to have an XY controller to control relative partial weightings (a tristimulus technique).
use the Grid external. download via PD CVS. i also have some unpublished patches to optimize a Kaos Pad controller for use in PD. let me know if you are interested, and i wil stick them on pure-data.org
ii)How to create a smart GUI
use graph-on-parent or the send and recieve capabilties of the GUI objects to communicate with subpatches.
iii)Converting a PD project to a VSTi
try this: http://crca.ucsd.edu/~jsarlo/pdvst/ no VSTi support yet, as far as i know, so build your environment to send all MIDI via loopback.
good luck, d.
On Mon, 17 Nov 2003 derek@x-i.net wrote:
Al,
Quoting Al Riley alrileyuk@yahoo.co.uk:
In the final implementation I would like to have an XY controller to control relative partial weightings (a tristimulus technique).
use the Grid external. download via PD CVS. i also have some unpublished patches to optimize a Kaos Pad controller for use in PD. let me know if you are interested, and i wil stick them on pure-data.org
[grid] is also included in the MacOS X and Windows installers. There is also [linuxmouse], [MouseState], [joystick], [linuxjoystick], [linuxevent], etc. for physical XY controllers.
.hc
ii)How to create a smart GUI
use graph-on-parent or the send and recieve capabilties of the GUI objects to communicate with subpatches.
iii)Converting a PD project to a VSTi
try this: http://crca.ucsd.edu/~jsarlo/pdvst/ no VSTi support yet, as far as i know, so build your environment to send all MIDI via loopback.
good luck, d.
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
zen
\
\
\[D[D[D[D
I also have a XY controller abstraction on pure-data.org. It has to be in edit mode, and would probably be too much for am OSX machine. It also has acceleration so that it slows down when it gets closer to the target. You can also chain them to create a cloud of following controllers.
www.ekran.org/ben/research/xy
Ben
Hi,
I'm new to PD and I'm about to embark on a project to design a multi-timbral additive synth.
In the final implementation I would like to have an XY controller to control relative partial weightings (a tristimulus technique).
Any help on basic implementation or approaches would be greatly appreciated.
Also need advice on: i)Basic additive synthesis in PD i.e. if anyone has a very basic additive synth patch, I would like to see it.
ii)How to create a smart GUI
iii)Converting a PD project to a VSTi
Thanks, Al
Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://mail.messenger.yahoo.co.uk
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
hi list, tried to try gem today. :)
keep getting:
Gem.dll: couldn't load Gem: can't load library
i've set -lib in all kind of ways. but no go.
i'm on windows me, running pd 0.36 - any known issues? do i need any more stuff than the Gem.dll? what's the difference between gem and any other external?
thanks
- michael
Hi Michael,
just checking, did you download and install the glut.dll ?
More info here:
http://gem.iem.at/download.html
Look in the gemlibs section...
cheers /
Martin
hi list, tried to try gem today. :)
keep getting:
Gem.dll: couldn't load Gem: can't load library
i've set -lib in all kind of ways. but no go.
i'm on windows me, running pd 0.36 - any known issues? do i need any more stuff than the Gem.dll? what's the difference between gem and any other external?
thanks
- michael
-- MichaelNisi.com
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
thanks for the quick responses guys. it was the glut.dll - me stupid. now i'm rollin' and pretty impressed by gem. having fun, my evening is saved. :)
bye
- michael
I find the large white expanse of Pd on my CRT rather hard on my eyes.
Is there a way to make Pd render in white with a black background instead of in black with a white background?
Even better would be to make Pd use the colours defined in the OS preferences.
I'm using Windows and have most applications I use set up to render in white with a black background, it would be great to have Pd able to do this too.
Claude
The Kzrysztof's toxy objects could definitely do this, they can control any aspect of the GUI which some basic Tcl commands.
They are in CVS, the MacOS X installer, and here:
http://suita.chopin.edu.pl/~czaja/miXed/externs/tow.html http://suita.chopin.edu.pl/~czaja/miXed/externs/scriptlets.html http://suita.chopin.edu.pl/~czaja/miXed/externs/toxy.html
They actually are quite amazing, you can contrrol any aspect of Pd's GUI with them, and do other really cool things. I've almost finished what i call 'xp4pd', short for extreme programming for Pd. It consists of a client and a server, and multiple people can edit the same patch in realtime. That patch will run locally on each machine, only the control data is going over the network, so it should be quite responsive.
.hc
On Mon, 17 Nov 2003, Claudius Maximus wrote:
I find the large white expanse of Pd on my CRT rather hard on my eyes.
Is there a way to make Pd render in white with a black background instead of in black with a white background?
Even better would be to make Pd use the colours defined in the OS preferences.
I'm using Windows and have most applications I use set up to render in white with a black background, it would be great to have Pd able to do this too.
Claude
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
zen
\
\
\[D[D[D[D
Hans-Christoph Steiner schrieb:
I've almost finished what i call 'xp4pd', short for extreme programming for Pd. It consists of a client and a server, and multiple people can edit the same patch in realtime. That patch will run locally on each machine, only the control data is going over the network, so it should be quite responsive.
This reminds me of an idea I'm carrying around with me for quite some time now: If we could run the Tcl/Tk GUI in a web browser (using the Tcl/Tk PlugIn) that would make Pd the perfect multi-user tool for the web. One would just open a web page and see the Pd patch (being executed on a server) and be able to interact with other users currently online... Maybe your solution could be extended in that direction since with the way it currently works in Pd one instance of pd is bound to one (or no in case of -nogui) instance of pd-gui and closing the GUI stops Pd. Having the possibility to disconnect / reconnect the gui would be a very nice feature!
Olaf
On Tue, Nov 18, 2003 at 01:11:03PM +0100, Olaf Matthes wrote:
If we could run the Tcl/Tk GUI in a web browser (using the Tcl/Tk PlugIn) that would make Pd the perfect multi-user tool for the web.
What about Flash with the flashserver external? What's needed is a small toolkit to create flash documents with special widgets for PD. Some of us will complain that Flash is proprietary, and I agree, it's "wrong"... There's also the Tcl/Tk web plugin, but the release version is too old, and the cvs version don't work.
couldn't it be done in pd.tk? I remember sorting out a *brown* (nice!) background for Pd just by simple editing of this file, but didn't manage to work out which line to change to make all lines/object boxes a light colour too.
matt
-=-=-=-=-=-=-=-=-=-=-=-=- http://www.loopit.org/ -=-=-=-=-=-=-=-=-=-=-=-=-
You could do it this way, but then you'd have to change it everytime you upgrade, or move to a different machine. If you made a toxy patch that did this, then you just need the patch. Plus the patch could be included with the Pd distros, then anyone could mess with Pd's colors easily.
.hc
On Tue, 18 Nov 2003, matthew jones wrote:
couldn't it be done in pd.tk? I remember sorting out a *brown* (nice!) background for Pd just by simple editing of this file, but didn't manage to work out which line to change to make all lines/object boxes a light colour too.
matt
-=-=-=-=-=-=-=-=-=-=-=-=- http://www.loopit.org/ -=-=-=-=-=-=-=-=-=-=-=-=-
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
zen
\
\
\[D[D[D[D
plus, its pretty simple and the toxy test patch "tot-bulk.pd" shows you how to do it right now :)
Hans-Christoph Steiner wrote:
You could do it this way, but then you'd have to change it everytime you upgrade, or move to a different machine. If you made a toxy patch that did this, then you just need the patch. Plus the patch could be included with the Pd distros, then anyone could mess with Pd's colors easily.
.hc
On Tue, 18 Nov 2003, matthew jones wrote:
couldn't it be done in pd.tk? I remember sorting out a *brown* (nice!) background for Pd just by simple editing of this file, but didn't manage to work out which line to change to make all lines/object boxes a light colour too.
matt
-=-=-=-=-=-=-=-=-=-=-=-=- http://www.loopit.org/ -=-=-=-=-=-=-=-=-=-=-=-=-
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
zen
\[D[D[D[D
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
hi,
changing canvas' -bg color (and keeping it changed) is simple enough.
Changing color of the canvas items (-fill color of connection lines and object text, -outline color of in/outlet rectangles, etc.) is virtually impossible, because these are hard-coded somewhere deep in g_text.c and what not. Some items are configured explicitly there, some take defaults, and they do not have grouping tags...
Neither tot, nor editing pd.tk, would do in this case.
Just for fun, though, one could send a tot something like:
tot .^.c config -bg black, tot .^.c itemconfig all -fill white
start editing, and wonder about disappearing objects...
frzysztok
Josh Steiner wrote:
plus, its pretty simple and the toxy test patch "tot-bulk.pd" shows you how to do it right now :)
I read:
toolkit to create flash documents with special widgets for PD. Some of us will complain that Flash is proprietary, and I agree, it's "wrong"...
I don't care about flash being proprietary or evil, it simply doesn't run on linuxppc (actually it runs only on linux x86, windos and mcos) so I'd like to see efforts put into more crossplatform solutions.
regards,
x
Selon CK x@meta.lo-res.org:
I read:
toolkit to create flash documents with special widgets for PD. Some of us will complain that Flash is proprietary, and I agree, it's "wrong"...
I don't care about flash being proprietary or evil, it simply doesn't run on linuxppc (actually it runs only on linux x86, windos and mcos) so I'd like to see efforts put into more crossplatform solutions.
some months ago I heard about a future version of Pure Data with an interface programmed in wx
On Tue, 18 Nov 2003 julien.breval@tremplin-utc.net wrote:
Selon CK x@meta.lo-res.org:
I read:
toolkit to create flash documents with special widgets for PD. Some of us will complain that Flash is proprietary, and I agree, it's "wrong"...
I don't care about flash being proprietary or evil, it simply doesn't run on linuxppc (actually it runs only on linux x86, windos and mcos) so I'd like to see efforts put into more crossplatform solutions.
some months ago I heard about a future version of Pure Data with an interface programmed in wx
AFAIK, there is no work being done on porting Pd to wx, it was just a possible direction for the future.
.hc
zen
\
\
\[D[D[D[D
On Tue, Nov 18, 2003 at 11:41:15AM -0800, Hans-Christoph Steiner wrote:
AFAIK, there is no work being done on porting Pd to wx, it was just a possible direction for the future.
python + wxwindow would give a nice gui and great portability.
- a nice gui thanks to native gui e.g. looks like OSX on mac, windows on mswindows, gnome/kde on linux
- great portability because python and wxworks run on linux, mac, windows
How easy is it to do a vector patcher in wx? Its not exactly an often done UI thing... I think this is actually the reason why we have tcl/tk problems, that we using a subset of vector drawing tools that were probably never envisioned for doing stuff like PD. I wonder if wx or anything else has done a better job of optimizing that particular aspect of the GUI. Is there enough devs doing that stuff to be worth it (from wx dev's perspective)?
I don't recall anyone complaining about the pull-down menus, or toggle boxes being too slow.
Ben
----- Original Message ----- From: "Jerome Etienne" jme@off.net To: "Hans-Christoph Steiner" hans@eds.org Cc: julien.breval@tremplin-utc.net; "CK" x@meta.lo-res.org; "Marc Lavallée" odradek@videotron.ca; pd-list@iem.at Sent: Tuesday, November 18, 2003 4:29 PM Subject: Re: [PD] Pd in white on black
On Tue, Nov 18, 2003 at 11:41:15AM -0800, Hans-Christoph Steiner wrote:
AFAIK, there is no work being done on porting Pd to wx, it was just a possible direction for the future.
python + wxwindow would give a nice gui and great portability.
- a nice gui thanks to native gui e.g. looks like OSX on mac, windows on mswindows, gnome/kde on linux
- great portability because python and wxworks run on linux, mac, windows
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
of course that begs the question, is wx/python measurably more efficient than tcl/tk? i've tried to find some objective benchmarks but have had no luck so far. i think really before the massive and disruptive process of porting pd to a new toolkit there needs to be an objective evaluation if tcl/tk really is to blame for the perceived graphical issues. i'd wager that there is a lot of optimising with the current tcl/tk gui left to be done before you can conclusively say that tcl/tk is junk.
Jerome Etienne wrote:
On Tue, Nov 18, 2003 at 11:41:15AM -0800, Hans-Christoph Steiner wrote:
AFAIK, there is no work being done on porting Pd to wx, it was just a possible direction for the future.
python + wxwindow would give a nice gui and great portability.
- a nice gui thanks to native gui e.g. looks like OSX on mac, windows
on mswindows, gnome/kde on linux
- great portability because python and wxworks run on linux, mac, windows
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
On Tue, Nov 18, 2003 at 02:07:13PM -0800, Josh Steiner wrote:
i'd wager that there is a lot of optimising with the current tcl/tk gui left to be done before you can conclusively say that tcl/tk is junk.
Tcl/tk is lighweight, fast, and cross-platform. There's no urgent reasons to rewrite a new gui, but it's nice to know that PD was designed to use other guis as well. Actually, if there's a new gui, it should be made as an option, to keep the possibility to use the goog old tcl/tk gui, which can certainly get better.
-- Marc
Marc Lavallée schrieb:
On Tue, Nov 18, 2003 at 01:11:03PM +0100, Olaf Matthes wrote:
If we could run the Tcl/Tk GUI in a web browser (using the Tcl/Tk PlugIn) that would make Pd the perfect multi-user tool for the web.
What about Flash with the flashserver external? What's needed is a small toolkit to create flash documents with special widgets for PD. Some of us will complain that Flash is proprietary, and I agree, it's "wrong"... There's also the Tcl/Tk web plugin, but the release version is too old, and the cvs version don't work.
I haven't checked the Tcl/Tk PlugIn for some time (maybe years), so maybe it's not really up to date. It just came to my mind because it would require only minor changes to the Pd code, I guess.
With flash, as CK already pointed out, we wouldn't be able to support all platforms Pd is currently working on. And additionally, a GUI for Pd could even be worth running on machines Pd is not running on.
So what about Java Applets? There should be Java support for almost every platform. But then we're getting damn close to the jMax way of doing it... and they seem to try to get rid of their Java GUI for some reason.
Technically speaking I could imagine something like this: hack pd-gui to become a server application and write a client software in (probably) Java to connect to it. The hacked pd-gui would then convert the Tcl/Tk stuff into something our client app likes. But that's probably pretty close to what Hans-Christoph is working on.
Olaf
So what about Java Applets? There should be Java support for almost every platform. But then we're getting damn close to the jMax way of doing it... and they seem to try to get rid of their Java GUI for some reason.
actually jMax is currently updating to wxPython
So what about Java Applets? There should be Java support for almost every platform. But then we're getting damn close to the jMax way of doing it... and they seem to try to get rid of their Java GUI for some reason.
I've been trying to communicate from proce55ing lately ( www.proce55ing.net ) it's very easy. comunicating with pdreceive is trivial with the builtin net functions (just adding a trailing ";") but you can also use OSC via javaOSC
I think it's the perfect platform for applet based GUIs
cheers,
gerard
On Tue, 18 Nov 2003, Olaf Matthes wrote:
Marc Lavallée schrieb:
On Tue, Nov 18, 2003 at 01:11:03PM +0100, Olaf Matthes wrote:
If we could run the Tcl/Tk GUI in a web browser (using the Tcl/Tk PlugIn) that would make Pd the perfect multi-user tool for the web.
What about Flash with the flashserver external? What's needed is a small toolkit to create flash documents with special widgets for PD. Some of us will complain that Flash is proprietary, and I agree, it's "wrong"... There's also the Tcl/Tk web plugin, but the release version is too old, and the cvs version don't work.
I haven't checked the Tcl/Tk PlugIn for some time (maybe years), so maybe it's not really up to date. It just came to my mind because it would require only minor changes to the Pd code, I guess.
With flash, as CK already pointed out, we wouldn't be able to support all platforms Pd is currently working on. And additionally, a GUI for Pd could even be worth running on machines Pd is not running on.
So what about Java Applets? There should be Java support for almost every platform. But then we're getting damn close to the jMax way of doing it... and they seem to try to get rid of their Java GUI for some reason.
Technically speaking I could imagine something like this: hack pd-gui to become a server application and write a client software in (probably) Java to connect to it. The hacked pd-gui would then convert the Tcl/Tk stuff into something our client app likes. But that's probably pretty close to what Hans-Christoph is working on.
Actually, the xp4pd is a surprisingly simple patch, thanks to Kzrysztof's [tot]. But unfortunately, its trapped on my laptop, which is in the shop right now. I forgot to cvs commit before bringing it in. Doh!
.hc
zen
\
\
\[D[D[D[D
"So what about Java Applets? There should be Java support for almost every platform. But then we're getting damn close to the jMax way of doing it... and they seem to try to get rid of their Java GUI for some reason."
Java GUI development is a bit of a time/resource eating monster. Not sure why - I've been involved in managing/working on a couple of projects recently with java GUIs and the GUI parts of the projects have just spiraled into huge jobs.
At the place I'm at now we are using c#.net which is not very cross platform
but very very easy to develop with. Not very suitable for pd though.
cheers
mark
Hello,
while trying to make a simple Karplus/Strong model I ran into something I cannot figure out. I cannot seem to get the delaytime smaller than 1.55 seconds thus the highest note is about 660 Hz. I can visually get the delaytime smaller in the numberbox but this had no effect on the actual delaytime whatsoever.
Does this have to do with the I/O blocksize and if so which value should I give this? If not is there another solution to get a smaller delay than 1.55 ms?
I used the [vd~] and [delread~] to generate the simple feedback model. I also used a [lop~] but switched this off to measure the highest pitch the delay model could generate. For the loss in a filterless model I used [*~].
Grtz Wilf
Yep... pd/doc/3.audio/examples/G04.control.blocksize.pd
details in chapter 7 of my book to appear in a week or so..
cheers Miller
On Wed, Nov 19, 2003 at 04:59:16PM +0100, Thurstan wrote:
Hello,
while trying to make a simple Karplus/Strong model I ran into something I cannot figure out. I cannot seem to get the delaytime smaller than 1.55 seconds thus the highest note is about 660 Hz. I can visually get the delaytime smaller in the numberbox but this had no effect on the actual delaytime whatsoever.
Does this have to do with the I/O blocksize and if so which value should I give this? If not is there another solution to get a smaller delay than 1.55 ms?
I used the [vd~] and [delread~] to generate the simple feedback model. I also used a [lop~] but switched this off to measure the highest pitch the delay model could generate. For the loss in a filterless model I used [*~].
Grtz Wilf
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
On Tue, 18 Nov 2003, Olaf Matthes wrote:
Hans-Christoph Steiner schrieb:
I've almost finished what i call 'xp4pd', short for extreme programming for Pd. It consists of a client and a server, and multiple people can edit the same patch in realtime. That patch will run locally on each machine, only the control data is going over the network, so it should be quite responsive.
This reminds me of an idea I'm carrying around with me for quite some time now: If we could run the Tcl/Tk GUI in a web browser (using the Tcl/Tk PlugIn) that would make Pd the perfect multi-user tool for the web. One would just open a web page and see the Pd patch (being executed on a server) and be able to interact with other users currently online... Maybe your solution could be extended in that direction since with the way it currently works in Pd one instance of pd is bound to one (or no in case of -nogui) instance of pd-gui and closing the GUI stops Pd. Having the possibility to disconnect / reconnect the gui would be a very nice feature!
That would be cool indeed. Wasn't there a project somewhere to turn Pd itself into a plug-in? Then you'd have the advantage of many processors, rather than having many web interfaces to one machine.
.hc
zen
\
\
\[D[D[D[D
-
0001 -
Al Riley -
B. Bogart -
ben＠ekran.org
-
CK -
Claudius Maximus -
derek＠x-i.net -
Hans-Christoph Steiner -
Jerome Etienne -
Josh Steiner -
julien.breval＠tremplin-utc.net -
Krzysztof Czaja -
lists＠martinmalm.com -
Marc Lavallée -
mark -
matthew jones -
Michael Nisi -
Miller Puckette -
Olaf Matthes -
Thurstan