[PD] [PD-announce] HoaLibrary for PD - High Order Ambisonics Library
Hi, The CICM is pleased to share the first release of HoaLibrary for Pure Data. HoaLibrary is a collection of C++ classes, FAUST functions and objects for Pure Data, Max and VST destined to high order Ambisonics sound reproduction. HoaLibrary allows musicians and composers to synthesize, transform and render sound fields in a creative and artistic way. This library facilitates the understanding and the appropriation of key concepts of Ambisonics. Thanks to original graphical interfaces a lot of new signal processings are allowed like diffuse sound field synthesis, perspective distortion or spatial filtering. HoaLibrary is free, open-source and made available by CICM, the centre of research on musical composition and computer science of the Paris 8 University. Objects: hoa.decoder~ : An ambisonic decoder (ambisonic, binaural, irregular configurations). hoa.encoder~ : An ambisonic encoder. hoa.map~ : An ambisonic sources spatializer. hoa.delay~ : An ambisonic sound field delay. hoa.freeverb~ : An implementation of the freeverb algorithm for Ambisonics. hoa.grain~ : An ambisonic granular synthesizer. hoa.map : A GUI to spatialize sources on a map. hoa.meter~ : A circular meter with sound field descriptor. hoa.optim~ : An ambisonic sound field optimization. hoa.pi : A good pi number. hoa.projector~ : A plane wave decomposer. hoa.recomposer~ : A plane wave recomposer to harmonics domain. hoa.ringmod~ : An ambisonic sound field ring modulation. hoa.rotate~ : An ambisonic sound field rotation external. hoa.scope~ : An ambisonic harmonic scope. hoa.space : A GUI to design ambisonic space. hoa.space~ : A plane wave spatial filter. hoa.wider~ : An ambisonic fractional orders simulator. Release: http://www.mshparisnord.fr/hoalibrary/en Sources: https://github.com/CICM/HoaLibrary Feedbacks are welcome. Thanks. Pierre ___ 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
Re: [PD] [PD-announce] HoaLibrary for PD - High Order Ambisonics Library
Am 2013-11-04 09:44, schrieb Pierre Guillot: Hi, The CICM is pleased to share the first release of HoaLibrary for Pure Data. HoaLibrary is a collection of C++ classes, FAUST functions and objects for Pure Data, Max and VST destined to high order Ambisonics sound reproduction. HoaLibrary allows musicians and composers to synthesize, transform and render sound fields in a creative and artistic way. This library facilitates the understanding and the appropriation of key concepts of Ambisonics. Thanks to original graphical interfaces a lot of new signal processings are allowed like diffuse sound field synthesis, perspective distortion or spatial filtering. HoaLibrary is free, open-source and made available by CICM, the centre of research on musical composition and computer science of the Paris 8 University. Objects: Hi, will there be a Linux puredata version? L. Willkomm Luxembourg ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] writesf~ and aiff files
I've reported what I think is a bug: http://sourceforge.net/p/pure-data/bugs/1123/ Thanks Peiman PS for future reference, what is considered good practise? Just file a bug report and leave it at that? *www.peimankhosravi.co.uk http://www.peimankhosravi.co.uk || RSS Feed http://peimankhosravi.co.uk/miscposts.rss || Concert News http://spectralkimia.wordpress.com/* ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Help with OSX App minefield
On 10/22/2013 12:55 PM, Jonathan Wilkes wrote:
On 10/21/2013 11:18 PM, Hans-Christoph Steiner wrote:
On 10/21/2013 03:59 PM, Jonathan Wilkes wrote:
On 10/21/2013 02:12 PM, Hans-Christoph Steiner wrote:
Carbon has been deprecated by Apple and might have been removed entirely.
It
will only ever be 32-bit, and starting in 10.7, everything is 64-bit.
Anything Carbon is dead, unless you're happy working with 10.6 and older.
I'm running Pd-extended and my Pd-l2ork port on 10.7.5. Both link
to the Carbon system libraries. Both run.
Considering that Apple has dropped support even for some older 64-bit Macs, I
think using Carbon is surely a dead end.
http://arstechnica.com/apple/2012/07/confirmed-mountain-lion-sends-some-64-bit-macs-gently-into-that-good-night/
What is the relevance of what you've written and linked to?
When I have time to look at what's required to get tkpath to use
the updated tkMac headers found in newer versions of tcl/tk, I'll do it.
Meanwhile people will have a working version of Pd-l2ork on OSX
to play with.
-Jonathan
I think I confused tkZinc and tkpath. tkpath seems to use CoreGraphics, which
is 64-bit.
Your determination is admirable, I just think there are better areas to focus
your efforts. Last I checked, tkpath is not really maintained. We should
really be talking about pulling the GUI functions out of the Pd core, then
people can do things like write a GUI in C++, which will be dramatically
faster than anything written in Tcl/Tk.
.hc
.hc
An update to the Pd-l2ork port:
* figured out how to build tkpath against the Carbon stuff. It runs fine
now.
* got some basic libraries compiled and installed to ship with the app.
(zexy, hcs, cyclone, and a few others).
* currently working on an issue with the Shift key sticking-- that is, if
I
do Shift-RightArrow to move an object by 10 pixels, when I release
Shift and then do RightArrow it continues moving the object by
10 pixels instead of 1 pixel. Once I fix that it should be usable.
Best,
Jonathan
.hc
On 10/09/2013 10:45 PM, Jonathan Wilkes wrote:
Update-- I've got a working Pd-l2ork, tkpath based App running on
OSX. (No ppc support, unfortunately.) Audio is running.
Minefields:
* I cannot for the life of me figure out how to build tkpath using the
Tcl/tk Frameworks (Carbon-based) inside Pd-l2ork.app instead of the
system ones. (Tried both Xcode and command line tools). Anybody
have hints for that?
* I can't figure out how to build the externals in extra. If I do
make the linker doesn't find any of the m_pd.h functions, even if
I do the ugly hack of copying m_pd.h to the directory.
* I'm abusing my function for returning the executable path in order
to get Pd to look for doc/ and extra/ inside the App (in addition to
the usual places on the system). Is there a trick to this?
* key presses/releases sometimes get stuck in one state or the other.
I think there's some simple tcl/tk hack for ignoring autokeys that may
remedy this, but I'm not sure yet.
Best,
Jonathan
On 10/07/2013 04:05 PM, Jonathan Wilkes wrote:
Hello,
I'm hoping some MacOSX gurus can help me traverse this
mine-field.
What I'm trying to do:
Port Pd-l2ork (quick-and-dirty) to MacOSX in the form of a Pd-l2ork.app
Minefields:
* Pd-l2ork uses tkpath, which is built to work with Carbon and not Cocoa.
So I
must use tcl/tk Framework that uses Carbon instead of Cocoa. That
should be
ok because Pd-extended.app is currently set up to use Carbon.
* Pd-l2ork uses the old pd.tk framework instead of the newer stuff from
the
gui-rewrite
What I've done so far:
* updated the configure file successfully
* made a workaround for statbuf from stat.h not existing on OSX (in
s_main.c)
* made a workaround for RTLD not existing after ./configure and trying to
make (s_loader.c)
* successfully compiled Pd-l2ork
* checked that tkpath actually works on OSX. It seems to work, using
tcl/tk
w/Carbon
instead of Cocoa.
* used otool and install_name_tool to change libPdTcl.dylib libraries to
point at the
App's Framework directory instead of system directories
* changed AppMain.tcl to launch pd.tk instead of pd-gui (which it does
successfully)
What crashes so far:
* inside pd.tk, I'm trying to do this:
load $pd_guidir/bin/libPdTcl.dylib
It finds the dylib fine but then it crashes, with the crash report
referencing the first line
of the following function of t_tkcmd.c in the backtrace:
int Pdtcl_Init(Tcl_Interp *interp)
{
const char *argv = Tcl_GetVar(interp, argv, 0);
***
Any ideas where to begin to debug this? Is there some code I can add to
Pdtcl_Init to print out some info I can use to tell where it's going
wrong?
I put the full error log here:
http://pastebin.com/duHdRrsY
Any suggestions appreciated.
-Jonathan
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
Re: [PD] Packages for Ubuntu 13.10?
I just uploaded Pd-extended 0.43.4 to be built on saucy and trusty. Please try them out and let me know if they work for you. If so I'll put them in the main apt.puredata.info repo. https://launchpad.net/~eighthave/+archive/pd-extended .hc On 10/23/2013 05:33 AM, Antonio Roberts wrote: Hi Joel, Thanks for the info On 23 October 2013 03:22, Joel Matthys jwmatt...@gmail.com wrote: You can still install it from the repo. Just use the raring distro instead of saucy. On 10/22/2013 06:47 PM, Antonio Roberts wrote: Hi, Will the Pd-extended repositories be updated for Ubuntu 13.10 at any point? Currently there's no way to install it other than compiling from source Kind regards, Antonio ___ 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] writesf~ and aiff files
Filing a bug report and discussing it on this list are both good options. Even better, submit a patch that fixes the issue :) .hc On 11/04/2013 06:29 AM, peiman khosravi wrote: I've reported what I think is a bug: http://sourceforge.net/p/pure-data/bugs/1123/ Thanks Peiman PS for future reference, what is considered good practise? Just file a bug report and leave it at that? *www.peimankhosravi.co.uk http://www.peimankhosravi.co.uk || RSS Feed http://peimankhosravi.co.uk/miscposts.rss || Concert News http://spectralkimia.wordpress.com/* ___ 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] Help with OSX App minefield
On 11/04/2013 09:51 AM, Hans-Christoph Steiner wrote: On 10/22/2013 12:55 PM, Jonathan Wilkes wrote: On 10/21/2013 11:18 PM, Hans-Christoph Steiner wrote: On 10/21/2013 03:59 PM, Jonathan Wilkes wrote: On 10/21/2013 02:12 PM, Hans-Christoph Steiner wrote: Carbon has been deprecated by Apple and might have been removed entirely. It will only ever be 32-bit, and starting in 10.7, everything is 64-bit. Anything Carbon is dead, unless you're happy working with 10.6 and older. I'm running Pd-extended and my Pd-l2ork port on 10.7.5. Both link to the Carbon system libraries. Both run. Considering that Apple has dropped support even for some older 64-bit Macs, I think using Carbon is surely a dead end. http://arstechnica.com/apple/2012/07/confirmed-mountain-lion-sends-some-64-bit-macs-gently-into-that-good-night/ What is the relevance of what you've written and linked to? When I have time to look at what's required to get tkpath to use the updated tkMac headers found in newer versions of tcl/tk, I'll do it. Meanwhile people will have a working version of Pd-l2ork on OSX to play with. -Jonathan I think I confused tkZinc and tkpath. tkpath seems to use CoreGraphics, which is 64-bit. Yes. AFAICT, getting it to work with Cocoa is a matter of revising tkpath to use the revised TkMacOSXInt.h header functions and structures in the newer versions of tcl/tk instead of the old ones. There are some hints by looking at the rest of tk that uses that header and seeing how they changed their code. Your determination is admirable, I just think there are better areas to focus your efforts. Last I checked, tkpath is not really maintained. We should really be talking about pulling the GUI functions out of the Pd core, then people can do things like write a GUI in C++, which will be dramatically faster than anything written in Tcl/Tk. But people aren't going to write a gui for Pd. There is already libpd and I don't see a bunch of elegant and efficient Pd frontends sprouting up because of that. (Though I'm sure there are a lot of projects that do cool things with it.) Writing a development environment is a gargantuan task, and testing out tkpath was literally 3 lines of code added to pdtk_canvas.tcl. Ivica said getting it to work fully was more effort than that, but the fact that it supports tk canvas commands allows a lot of improvements to the interface without having to do a complete rewrite of everything g_*.[ch] And of course removing GUI function from the Pd core can be done in addition to the tkpath improvements. Once you get FUDI messages in both directions, you'll still have a fully-functional gui dev environment in tcl/tk. I'm not convinced there are the resources in the Pd community to fund doing all the work required to use a different GUI toolkit, plus making all the redesign and testing speed improvements that another toolkit would bring. -Jonathan .hc .hc An update to the Pd-l2ork port: * figured out how to build tkpath against the Carbon stuff. It runs fine now. * got some basic libraries compiled and installed to ship with the app. (zexy, hcs, cyclone, and a few others). * currently working on an issue with the Shift key sticking-- that is, if I do Shift-RightArrow to move an object by 10 pixels, when I release Shift and then do RightArrow it continues moving the object by 10 pixels instead of 1 pixel. Once I fix that it should be usable. Best, Jonathan .hc On 10/09/2013 10:45 PM, Jonathan Wilkes wrote: Update-- I've got a working Pd-l2ork, tkpath based App running on OSX. (No ppc support, unfortunately.) Audio is running. Minefields: * I cannot for the life of me figure out how to build tkpath using the Tcl/tk Frameworks (Carbon-based) inside Pd-l2ork.app instead of the system ones. (Tried both Xcode and command line tools). Anybody have hints for that? * I can't figure out how to build the externals in extra. If I do make the linker doesn't find any of the m_pd.h functions, even if I do the ugly hack of copying m_pd.h to the directory. * I'm abusing my function for returning the executable path in order to get Pd to look for doc/ and extra/ inside the App (in addition to the usual places on the system). Is there a trick to this? * key presses/releases sometimes get stuck in one state or the other. I think there's some simple tcl/tk hack for ignoring autokeys that may remedy this, but I'm not sure yet. Best, Jonathan On 10/07/2013 04:05 PM, Jonathan Wilkes wrote: Hello, I'm hoping some MacOSX gurus can help me traverse this mine-field. What I'm trying to do: Port Pd-l2ork (quick-and-dirty) to MacOSX in the form of a Pd-l2ork.app Minefields: * Pd-l2ork uses tkpath, which is built to work with Carbon and not Cocoa. So I must use tcl/tk Framework that uses Carbon instead of Cocoa. That should be ok because Pd-extended.app is currently set up to use Carbon. * Pd-l2ork uses the old pd.tk framework instead of the newer stuff from
Re: [PD] writesf~ and aiff files
Cool, thanks! P *www.peimankhosravi.co.uk http://www.peimankhosravi.co.uk || RSS Feed http://peimankhosravi.co.uk/miscposts.rss || Concert News http://spectralkimia.wordpress.com/* On 4 November 2013 15:04, Hans-Christoph Steiner h...@at.or.at wrote: Filing a bug report and discussing it on this list are both good options. Even better, submit a patch that fixes the issue :) .hc On 11/04/2013 06:29 AM, peiman khosravi wrote: I've reported what I think is a bug: http://sourceforge.net/p/pure-data/bugs/1123/ Thanks Peiman PS for future reference, what is considered good practise? Just file a bug report and leave it at that? *www.peimankhosravi.co.uk http://www.peimankhosravi.co.uk || RSS Feed http://peimankhosravi.co.uk/miscposts.rss || Concert News http://spectralkimia.wordpress.com/* ___ 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] Help with OSX App minefield
On Nov 4, 2013, at 1:35 PM, pd-list-requ...@iem.at wrote: But people aren't going to write a gui for Pd. There is already libpd and I don't see a bunch of elegant and efficient Pd frontends sprouting up because of that. (Though I'm sure there are a lot of projects that do cool things with it.) The main reason for this is that we haven't pulled out the gui elements yet. There isn't yet an interface in libpd to edit the object graph and I'm not sure where the plans are on that. Once it's there I'm sure we could see some interesting things. I imagine I could add patch editing to PdParty using Objective-C in about a week or two if I had such an interface. I agree with both Han's point that a long term goal of cleanly separating the gui from the dsp is what we want. At the same time, I agree with Jonathan in that we shouldn't abandon/neglect what's already here and working. The overall plan, as far as I know, is once there is a clean separation the dsp core from the gui, the pd tcl/tk app would then be updated to use libpd. As for when that would happen, who knows? Anyone want to hire Jonathan, Hans, me, etc at a research lab to do it? I'll be available in the spring :D Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Help with OSX App minefield
...tkpath in pd-l2ork, just like cwiid library is a fork that has more bug fixes and features than any other variant since the core of either packages is not maintained uniformly or at all, so tkpath is very much maintained inside pd-l2ork. There's also on my short-term a todo list to overhaul vanilla gui objects so that they queue their actions rather than requesting the same action multiple times per refresh and bogging down the networked nature of the gui. On Nov 4, 2013 3:52 PM, Dan Wilcox danomat...@gmail.com wrote: On Nov 4, 2013, at 1:35 PM, pd-list-requ...@iem.at wrote: But people aren't going to write a gui for Pd. There is already libpd and I don't see a bunch of elegant and efficient Pd frontends sprouting up because of that. (Though I'm sure there are a lot of projects that do cool things with it.) The main reason for this is that we haven't pulled out the gui elements yet. There isn't yet an interface in libpd to edit the object graph and I'm not sure where the plans are on that. Once it's there I'm sure we could see some interesting things. I imagine I could add patch editing to PdParty using Objective-C in about a week or two if I had such an interface. I agree with both Han's point that a long term goal of cleanly separating the gui from the dsp is what we want. At the same time, I agree with Jonathan in that we shouldn't abandon/neglect what's already here and working. The overall plan, as far as I know, is once there is a clean separation the dsp core from the gui, the pd tcl/tk app would then be updated to use libpd. As for when that would happen, who knows? Anyone want to hire Jonathan, Hans, me, etc at a research lab to do it? I'll be available in the spring :D Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ 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] Help with OSX App minefield
On Nov 4, 2013, at 1:42 PM, Jonathan Wilkes wrote: On 11/04/2013 09:51 AM, Hans-Christoph Steiner wrote: On 10/22/2013 12:55 PM, Jonathan Wilkes wrote: On 10/21/2013 11:18 PM, Hans-Christoph Steiner wrote: On 10/21/2013 03:59 PM, Jonathan Wilkes wrote: On 10/21/2013 02:12 PM, Hans-Christoph Steiner wrote: Carbon has been deprecated by Apple and might have been removed entirely. It will only ever be 32-bit, and starting in 10.7, everything is 64-bit. Anything Carbon is dead, unless you're happy working with 10.6 and older. I'm running Pd-extended and my Pd-l2ork port on 10.7.5. Both link to the Carbon system libraries. Both run. Considering that Apple has dropped support even for some older 64-bit Macs, I think using Carbon is surely a dead end. http://arstechnica.com/apple/2012/07/confirmed-mountain-lion-sends-some-64-bit-macs-gently-into-that-good-night/ What is the relevance of what you've written and linked to? When I have time to look at what's required to get tkpath to use the updated tkMac headers found in newer versions of tcl/tk, I'll do it. Meanwhile people will have a working version of Pd-l2ork on OSX to play with. -Jonathan I think I confused tkZinc and tkpath. tkpath seems to use CoreGraphics, which is 64-bit. Yes. AFAICT, getting it to work with Cocoa is a matter of revising tkpath to use the revised TkMacOSXInt.h header functions and structures in the newer versions of tcl/tk instead of the old ones. There are some hints by looking at the rest of tk that uses that header and seeing how they changed their code. Your determination is admirable, I just think there are better areas to focus your efforts. Last I checked, tkpath is not really maintained. We should really be talking about pulling the GUI functions out of the Pd core, then people can do things like write a GUI in C++, which will be dramatically faster than anything written in Tcl/Tk. But people aren't going to write a gui for Pd. There is already libpd and I don't see a bunch of elegant and efficient Pd frontends sprouting up because of that. (Though I'm sure there are a lot of projects that do cool things with it.) Writing a development environment is a gargantuan task, and testing out tkpath was literally 3 lines of code added to pdtk_canvas.tcl. Ivica said getting it to work fully was more effort than that, but the fact that it supports tk canvas commands allows a lot of improvements to the interface without having to do a complete rewrite of everything g_*.[ch] And of course removing GUI function from the Pd core can be done in addition to the tkpath improvements. Once you get FUDI messages in both directions, you'll still have a fully-functional gui dev environment in tcl/tk. I'm not convinced there are the resources in the Pd community to fund doing all the work required to use a different GUI toolkit, plus making all the redesign and testing speed improvements that another toolkit would bring. -Jonathan I'm not proposing that we spend more time on this, but rather that we coordinate efforts and work smartly. Sure, we can keep patching up the existing Pd GUI stuff, and hacking in old Tk code, there has been a lot of that over the years. If we instead invest in the up front work of ripping out the GUI code from pd core, then it becomes drastically easier to write a modern, efficient GUI in whatever toolkit. libpd has not addressed this particular issue, but it will become more valuable if the GUI was truly separate from the core. But the Pd dev community has always been not so good at coordinated efforts. There is a history of lots of effort going into semi-compatible dev forks which mostly die out after a run (pd-devel, desiredata, vibrez, etc. etc.) Perhaps Pd-extended or pd-l2ork will be the next one to die out... .hc ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
