Re: [PD-dev] Functional Programming C code generation
Btw, Tom, great to see you back in Pure Data business! gr~~~ -- Thomas Grill http://g.org Am 14.05.2013 um 18:18 schrieb Tom Schouten: Hi Pd devs Is there anyone here interested in Functional Programming and C code generation for DSP code? I'm working on a system for DSP code development based on the principle of Abstract Interpretation http://en.wikipedia.org/wiki/Abstract_interpretation Basically, it will allow several interpretations of a single specification program: - specification as a pure functional program - imperative C code generation (for passing to C compiler or LLVM) - Z transform for frequency plots of (linearized) transfer function - automatic differentiation for all kinds of derivative-based tricks - ... It is written in Racket http://racket-lang.org/ It's starting to get to a point where it is actually useful (there is a basic synth core) and could use some feedback, but please note it is very experimental and still needs a lot of work. Familiarity with Racket is probably a prerequisite at this point to make sense of it. Current code is here: http://zwizwa.be/darcs/meta/rai/ It is part of a darcs archive that can be fetched using darcs gethttp://zwizwa.be/darcs/meta I use Pd for most of the experiments. There is a generator for Pd externs, and a live coding reload mechanism that can reload recompiled processing code without messing up internal state, as long as the types are compatible. Cheers Tom ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Rewriting a unified phasor / metro object for reading tables
Hi Ed, maybe the ramp abstraction in http://g.org/research/software/upp/upp-tut6c/ is of use for you. It doesn't wrap but just ramp endlessly. gr~~~ -- Thomas Grill http://g.org Am 08.05.2013 um 23:00 schrieb Ed Kelly: Hi Lists(s), I'm rewriting phasor~ and unifying it with metro so that a pulse is generated from the boundaries of each ramp - so that bars of music can be read using tabread~ objects with a sample-accurate metro. I'm sure someone will say this can already be done, but it has to be dropped into the Ninja Jamm patch, so there isn't really time to rewrite the rest of the patch. I don't fully understand the way phasor~ wraps, but I have the object firing out bar numbers correctly. I'm putting clocks in for 16ths and 24ths of the beat, initiated on each wrap. I need to minimise CPU, so what I want to know is this: Does phasor~ always start from 0 and go to 1, i.e. is there always a signal value of 0 at the start of the ramp and a signal value of 1 at the end? As I write this, my common sense tells me it should be yes but I want to make sure. I suppose I should just try it really... Cheers, Ed Ninja Jamm - a revolutionary new musix remix app from Ninja Tune and Seeper, for iPhone and iPad http://www.ninjajamm.com/ Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/ ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [PD] libpd netreceive
Hi Peter,
at least on iOS, the whole thing boils down to the patch below.
I added two initialization functions to libpd_init, the first
sys_findprogdir for finding the pd binary directory (actually to initialize
the symbol sys_libdir which can also be done manually), and second
sys_startgui to initialize the data structures for networking. That this
fundamental functionality is mangled with GUI-related code is not pretty
and should certainly be refactored (in Pd proper).
The polling happens in the PROCESS macro, after audio has been processed. I
think using a sleep time of 0 it should be non-blocking, but it would
definitely be better (in sys_domicrosleep) to avoid calling the system
function Sleep (only matters for WIN32) for timeouts of 0. Maybe Miller
should review that.
I am not sure whether using memory management functions in an audio
callback is a problem - it shouldn't, as Miller certainly had a look at
that. This happens because the incoming networking data is stored in
dynamically allocated binbuf structures.
That's my report - it works for me now.
all the best,
gr~~~
--
--- a/libpd_wrapper/z_libpd.c
+++ b/libpd_wrapper/z_libpd.c
@@ -20,6 +20,8 @@
#include g_all_guis.h
void pd_init(void);
+void sys_findprogdir(char *progname);
+int sys_startgui(const char *guipath);
t_libpd_printhook libpd_printhook = NULL;
t_libpd_banghook libpd_banghook = NULL;
@@ -65,7 +67,9 @@ void libpd_init(void) {
sys_nmidiout = 0;
sys_time = 0;
pd_init();
+ sys_findprogdir(); /* set sys_progname, guipath */
libpdreceive_setup();
+ sys_startgui(sys_libdir-s_name); /* start the gui */
sys_set_audio_api(API_DUMMY);
sys_searchpath = NULL;
}
@@ -128,6 +132,7 @@ static const t_sample sample_to_short = SHRT_MAX,
} \
} \
} \
+ sys_microsleep(0); \
return 0;
int libpd_process_short(int ticks, short *inBuffer, short *outBuffer) {
2013/1/21 Peter Brinkmann peter.brinkm...@googlemail.com
Hi Thomas,
There's no mailing list for libpd, but there is a forum:
http://createdigitalnoise.com/categories/pd-everywhere In any case, this
does seem like a question for pd-dev, so we're in the right place :)
About sys_microsleep, there are two potential problems that I'm concerned
about about: The first is that it might block, but that doesn't seem to be
the case since it's being called in the audio callback. The second concern
is that I'm not sure how this low-level access to network sockets might
behave on Android (which requires special permissions for internet access).
I'm expecting that it'll be okay, but we need to make sure. Please let me
know how it goes!
Best,
Peter
On Mon, Jan 21, 2013 at 6:43 AM, Thomas Grill g...@g.org wrote:
Ok Peter, let's move this over to pd-dev. There is no specific libpd
list, is it?
I have now quickly looked into what the context of the socket polling is
like in Pd.
It is even done in the audio callback (via sys_pollgui) if this is
enabled, so it can't really have serious side effects. As far as i have
seen libpd also uses a callback based approach for audio, at least for iOS.
Maybe introducing a sys_microsleep(0,1) in the audio callback does the
trick? I will test that now.
That said, i'm totally unaware of the details of other implementations.
all the best,
gr
2013/1/21 Peter Brinkmann peter.brinkm...@googlemail.com
Hi Thomas,
I have to admit that I didn't realize that netreceive requires an extra
polling step. So, I'm afraid that netreceive is currently broken.
The question is what to do about this. I took a quick look at
sys_domicrosleep and didn't immediately see how it works. I wouldn't mind
integrating it into libpd somehow, but I want to be sure that there won't
be any weird side effects. This seems slightly off-topic for pd-list. Shall
we talk about this on pd-dev?
Cheers,
Peter
On Sun, Jan 20, 2013 at 6:42 PM, Thomas Grill g...@g.org wrote:
Hi all,
i am new to libpd and i have run into problems using netreceive on ios
5.1.
While netsend works perfectly, netreceive doesn't work at all. Senders
can connect to the receiving socket, but netreceive wouldn't spit out any
data.
Looking at the code, it seems to me that the polling of the net sockets
(done in plain Pure Data in s_inter.c / sys_domicrosleep) is not called in
libpd at all. I also couldn't find a different place where this is done.
Does that mean that libpd doesn't currently service incoming socket
data?
Thanks for clarification, all the best,
gr~~~
--
Thomas Grill
http://g.org
___
pd-l...@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
--
Thomas Grill
http://g.org
--
Thomas Grill
http://g.org
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Flext compiled objects in Pd 0.43.1 (fluid~ py/pyext)
Hi Glerm, i would be interested on the circumstances why pyext doesn't load. Are you sure that you used a valid python script (to be found in the current patcher directory or the pd path? Because, if not, pyext won't load. gr~~~ Am 07.08.2012 um 22:40 schrieb glerm soares: Hello, I just compiled and tested Pd 0.43.1 since a long time using 0.42.5 and missed some objects I always used. I want to know if some people are having the same trouble than me with 2 flext compiled objects mainly - [ fluid~ ] [ pyext ] my system is Ubuntu Oneiric 32bits,kernel 3.0.0-20-generic-pae but I don't think it's an OS problem. I could compile the binaries .pd_linux and they are in the correct folders (/usr/lib/pd-extended/extra) but py/pyext - pyext doesn't load (even when I use -lib py in statup or [import py]) - I saw similar issues in list history but my problem is not about not loading the lib cause py loads (but AFAIK all the examples uses pyext) fluid~ - the object loads but when I load a soundfount pd crashes with a signal - watchdog: signaling pd... watchdog: signaling pd... watchdog: signaling pd... (something related to tcl/tk GUI ??) Some could say I should had separated the 2 objects issues in different threads for this mailinglist, but since I think most of pd(extended) users don't even try to compile flext objects I think this is the best subject title for now... so the question is: who already could run some of those 2 objects at Pd 0.43.1 and if maybe it's some with flext compilation problem? or whatever, some tip about one of those objects? thanx glerm ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev -- Thomas Grill http://g.org +43 699 19715543 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] open_via_path / close file - WIndows CRT problems
Hi all, when trying to trace a bug in one of my externals i came across what could be an issue in the PD API. The header m_pd.h exposes the function open_via_path which can be used in externals to search file in the PD search path. On success it opens the file and returns a file handle, which can in turn be used by the external code. This doesn't seem to be a problem on Unix-based systems. On Windows, under certain circumstances [1], PD and the external use separate copies of the CRT, meaning that passing the file handle and using POSIX-style file functions between dynamically linked binaries is not really possible. The file handle would not be valid in the external. This happens when at least one party is linked with the threaded static CRT, which is the default with PD and most externals. Now, i'm wondering how this problem can have been hidden for so long. Are there no externals using open_via_path and running under Windows? This must be a problem for all script loader externals relying on the PD path, like my py/pyext external. Am i doing something wrong, or is there a known solution/workaround etc.? Thanks and all the best, Thomas [1] http://msdn.microsoft.com/en-us/library/ms235460(v=vs.80).aspx -- Thomas Grill http://g.org ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] open_via_path / close file - WIndows CRT problems
I see, thanks! That's perfect - sorry for not being up to date. gr~~~ Am 03.07.2012 um 15:49 schrieb IOhannes m zmoelnig: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-07-03 15:40, IOhannes m zmoelnig wrote: Pd-0.43 introduced sys_close() in order to have the same CRT implementation open and close the file. prior version of Pd lack this function and therefore there a number of file-handle leakage bugs were reported. sp the workaround is actually to use open_via_path() to get the full patch of the file you want to open, sys_close() the filehandle and then use the full-path to open the file yourself. fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/y+EkACgkQkX2Xpv6ydvTkCwCfRvO9WVlNjg2/AZ0unQgs6qYs xLkAnAwTrGl7B/uqClNFrJP0o1VDzEpc =oSId -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev -- Thomas Grill http://g.org +43 699 19715543 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Xcode 4: Debug pd-external
Hi, i haven't used Xcode4 yet. For older versions i don't define the application bundle as executable, but rather the unix program, which is in e.g. /Applications/Pd-0.43-0.app/Contents/Resources/bin/pd My experience is that pd-extended won't take any command-line parameters (which is very useful for debugging), as opposed to pd-vanilla. gr~~~ Am 30.08.2011 um 15:20 schrieb Patrick Gampp: Hi, I tried to debug my puredata external with Xcode4. What I did so far is: 1) In the 'edit scheme'-menu, I added in the 'Executable'-list: Pd-extended.app. 2) Build configuration is Debug 3) Debugger is GDB. 4) I set some breakpoints in my source file. When I hit Run, pd starts and I open my patch, where the external is, which I want to debug. The patch runs, but Xcode does not stop at the given breakpoints. Do you know what I am doing wrong here? Thanks, Patrick ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev -- Thomas Grill http://g.org +43 699 19715543 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] flext and gnu/windows - 'undefined reference' with pd global vars?
Am 04.04.2011 um 17:46 schrieb dmotd: On 04/05/2011 01:14 AM, Hans-Christoph Steiner wrote: 'undefined reference' generally means that the linker has found symbols in the .o files that it can't find a reference to. I.e. take the function 'foo', if myobject.o uses foo() from the bar lib, and the bar lib is not including the linking, because its not specified or not in the lib path, the you'll get an 'undefined reference'. Basically it means it can't find the code that matches a given symbol (i.e. function, variable, etc). .hc yes, i'm quite aware of what causes an 'undefined reference', but the flext lib should already be linking to pd.dll with -lpd and the locations -L check out.. it only complains of a small handfull of the many symbols that flext uses from pd (it is afterall a programming interface which uses pds api extensively). the problem is caused only by the global data defined in the pd.dll (garray_class, s_float, etc.) not by function protoypes gr~~~ ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [flext] Fwd: fixing Flext for 64-bit?
Do you think you (or someone else) will have the time in the near future to solve the bug? sure, if a genuine bug shows up i'll usually fix it quickly. Missing features take much longer. gr~~~ ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [flext] Fwd: fixing Flext for 64-bit?
the message [mul array3 array1 array2 works only on the first half of the array3 instead the message [add array3 array1 array2 you mean the latter add function works as it should? - this behaviour is correct (I don't think so)? true, i suspect a bug - this behaviour is due to the 64-bit? very probable, but it should be fixed nonetheless gr~~~ ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [flext] Fwd: fixing Flext for 64-bit?
thanks for your kind words. I haven't given up the hope that someday someone will find the time to integrate the flext-based externals into the autobuild structure and, consequently, pd-extended. gr~~~ 2010/3/9 Dario Pedrioli dariopedri...@gmail.com: Thanks a lot Thomas. Now it compile fine! I pick the occasion to say that your work for pd (flext, pool, py, etc...) is fantastic. Many many many thanks! ciao, Dario 2010/3/9 Thomas Grill g...@g.org Hi Dario, please check out py from svn and try again. gr~~~ Am 09.03.2010 um 09:48 schrieb Dario Pedrioli: Hi all, I'm trying to compile py/pyext on ubuntu 9.04 64-bit machine PD 0.42.5 with flext rev 3659 I've got no problems. with flext rev 3723 I've got the error below: ubu...@ubuntu-desktop:~/pd/ source/py_3723$ sh ../flext_3723/build.sh pd gcc make -f ../flext_3723/buildsys/gnumake-sub.mak PLATFORM=lnx RTSYS=pd COMPILER=gcc BUILDPATH=../flext_3723/buildsys/ PKGINFO=package.txt BUILDCLASS=ext USRCONFIG=config.txt USRMAKE=build/gnumake-lnx-gcc.inc TARGETMODE=release TARGETTYPE=multi THREADED=1 _build_ make[1]: ingresso nella directory ?/home/ubuntu/pd/source/py_3723? mkdir -p pd-linux/release-multi/ g++ -c -pthread -fPIC -fvisibility-inlines-hidden -DPY_EXPORTS -DPY_NUMPY -DPY_USE_GIL -DNDEBUG -DFLEXT_THREADS -DFLEXT_SYS=2 -DPD -I/usr/include/python2.6 -I/home/ubuntu/pd/source/pd-0.42-5/src -I/usr/local/include/stk -I/usr/local/include/sndobj -I/usr/local/include/flext source/pybuffer.cpp -o pd-linux/release-multi/pybuffer.opp source/pybuffer.cpp:154: warning: deprecated conversion from string constant to ?char*? source/pybuffer.cpp: In function ?int buffer_ass_slice(PyObject*, Py_ssize_t, Py_ssize_t, PyObject*)?: source/pybuffer.cpp:406: error: no matching function for call to ?flext_multi::CopySamples(flext_multi::buffer::Element*, t_sample*, int)? /usr/local/include/flext/flsupport.h:425: note: candidates are: static void flext_multi::CopySamples(t_sample*, const t_sample*, int) Someone can help? PS: I'm trying rev 3723 because of 64-bit buffer patch ( http://markmail.org/message/6v52tlvllwvcwilj#query:+page:1+mid:6hpplp4wfi4u6vkc+state:resultsg...@g.org ) My goal is to handle arrays directly in python, but with the rev 3659 I'm only get half of the array inside py (the other half is set to zero). Am I on the right way to fix my problem? Thanks and ciao! ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev -- Thomas Grill http://g.org ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [flext] Fwd: fixing Flext for 64-bit?
Hi Dario, please check out py from svn and try again. gr~~~ Am 09.03.2010 um 09:48 schrieb Dario Pedrioli: Hi all, I'm trying to compile py/pyext on ubuntu 9.04 64-bit machine PD 0.42.5 with flext rev 3659 I've got no problems. with flext rev 3723 I've got the error below: ubu...@ubuntu-desktop:~/pd/ source/py_3723$ sh ../flext_3723/build.sh pd gcc make -f ../flext_3723/buildsys/gnumake-sub.mak PLATFORM=lnx RTSYS=pd COMPILER=gcc BUILDPATH=../flext_3723/buildsys/ PKGINFO=package.txt BUILDCLASS=ext USRCONFIG=config.txt USRMAKE=build/gnumake-lnx-gcc.inc TARGETMODE=release TARGETTYPE=multi THREADED=1 _build_ make[1]: ingresso nella directory ?/home/ubuntu/pd/source/py_3723? mkdir -p pd-linux/release-multi/ g++ -c -pthread -fPIC -fvisibility-inlines-hidden -DPY_EXPORTS -DPY_NUMPY -DPY_USE_GIL -DNDEBUG -DFLEXT_THREADS -DFLEXT_SYS=2 -DPD -I/usr/include/python2.6 -I/home/ubuntu/pd/source/pd-0.42-5/src -I/usr/local/include/stk -I/usr/local/include/sndobj -I/usr/local/include/flext source/pybuffer.cpp -o pd-linux/release-multi/pybuffer.opp source/pybuffer.cpp:154: warning: deprecated conversion from string constant to ?char*? source/pybuffer.cpp: In function ?int buffer_ass_slice(PyObject*, Py_ssize_t, Py_ssize_t, PyObject*)?: source/pybuffer.cpp:406: error: no matching function for call to ?flext_multi::CopySamples(flext_multi::buffer::Element*, t_sample*, int)? /usr/local/include/flext/flsupport.h:425: note: candidates are: static void flext_multi::CopySamples(t_sample*, const t_sample*, int) Someone can help? PS: I'm trying rev 3723 because of 64-bit buffer patch ( http://markmail.org/message/6v52tlvllwvcwilj#query:+page:1+mid:6hpplp4wfi4u6vkc+state:resultsg...@g.org ) My goal is to handle arrays directly in python, but with the rev 3659 I'm only get half of the array inside py (the other half is set to zero). Am I on the right way to fix my problem? Thanks and ciao! ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [flext] Fwd: fixing Flext for 64-bit?
Hi Spencer, hi all, i finally committed 64-bit fixes to flext. The way buffers are to be accessed now slightly differ from the patches you sent me... i use the indexing operator [] instead of Peek and Poke functions. Existing code should continue to work. If compiled for 64-bit systems indexed [] access has to be used directly on flext::Buffer instances (instead of t_sample * vectors). I adapted the tutorial/buffer example accordingly to reflect the new method. gr~~~ Am 29.10.2009 um 13:21 schrieb Thomas Grill: Hi Spencer, many thanks for the patch... i'm not yet familiar with the way how pd uses arrays in 64 bit mode, but i'll check out your modifications and commit them to the svn. gr~~~ Am 24.10.2009 um 23:24 schrieb Spencer Russell: Attached is a patch that should make flext buffer handling 64-bit compatible. It adds new wrapper functions buffer::Peek(int index) and buffer::Poke(int index, t_sample value) to access a buffer's data. New externals should uses these instead of accessing the data array directly, because with newer PDs that doesn't work. I've also updated the buffer1 example to use the new API wrappers. The issue is that arrays in PD are of type t_word, which is a union that can contain a variety of data, including pointers. In 32-bit architectures you can pretty much ignore that it's a union because floats and pointers are the same size, but on 64-bit architectures it's important to use the w_float member of the union to access stored floats. This patch shouldn't break any old externals unless they're used with PD 0.41 (but then they'd be broken, anyways). I don't have access to an OS X machine or Max/MSP, so I've so far only tested this on 64-bit linux/PD. YMMV. Can someone explain to me why pd's arrays are arrays of t_word instead of t_sample? -s- On Thu, Oct 1, 2009 at 10:41 AM, dmotd dm...@gmx.net wrote: hi spencer, afaik there hasn't been any progress with the 64bit translation, i was going to attempt it last time i needed it but got distracted along the way - and i sent a similar message to thomas at the time, so its going to be on his todo list, but proabably not a priority. i'd be happy to test any changes you make, and collaborate time permitted. ciao, dmotd Spencer Russell wrote: Thought this should probably go to the list: -- Forwarded message -- From: Spencer Russell spencer.f.russ...@gmail.com Date: Tue, Sep 29, 2009 at 11:13 AM Subject: Re: fixing Flext for 64-bit? To: Thomas Grill g...@g.org Am 29.09.2009 um 15:00 schrieb Spencer Russell: Hi Thomas, I'm writing a Flext external to implement Iannis Xenakis's Dynamic Stochastic Synthesis, and running into some problems with buffer handling on my 64-bit system. It seems that currently flext uses the deprecated garray_getfloatarray() function and t_sample arrays, instead of the new garray_getfloatwords() function with t_word unions. Changing the code would make flext incompatible with older versions of PD, but some other external developers are currently using an #ifdef workaround to change to the newer API call for PD versions that support it. I was going to get in there and see if i can't get it working in the flext code, but I wanted to check with you first to see if you had already done any work on that front. I'll of course send you the diffs if i get it working. Shouldn't be that hard and i think it should really only effect the buffer-handling code, but I don't know the flext codebase that well so there might be some hidden gotchas. -spencer On Tue, Sep 29, 2009 at 9:08 AM, Thomas Grill g...@g.org wrote: Hi Spencer, i know that this is something i should work on, but my schedule is insanely tight and i don't get to it. So, if you can make any contributions and testing on 64-bit systems i'd be very grateful. I'd also go for the Pd API selecton by #ifdef statements. gr~~~ As far as i can tell, PD since 0.41 changed arrays to be arrays of t_words instead of t_samples or t_floats. On 32-bit architectures they're all the same size, but on 64-bit architectures t_word is 64-bit, while t_sample and t_float are still 32-bit. For a normal PD external, it's pretty easy to just modify the external to use t_words, but I'm not sure the best way to modify flext to do this without breaking compatibility for externals. One problem is that when an external calls mybuffer.Data(), what should they receive? if the system is PD newer than 0.41, they should receive a pointer to t_word, but MAX or older PD should receive a pointer to t_sample. The other problem is that accessing an element for newer PD requires accessing the w_float member of the t_word union, but the others just use the element itself. There could be some sort of GetValue() wrapper for buffer elements that could be made cross-platform, but would break compatibility with existing flext externals, so that seems seriously sub-optimal
Re: [PD-dev] [flext] Fwd: fixing Flext for 64-bit?
Hi Spencer, many thanks for the patch... i'm not yet familiar with the way how pd uses arrays in 64 bit mode, but i'll check out your modifications and commit them to the svn. gr~~~ Am 24.10.2009 um 23:24 schrieb Spencer Russell: Attached is a patch that should make flext buffer handling 64-bit compatible. It adds new wrapper functions buffer::Peek(int index) and buffer::Poke(int index, t_sample value) to access a buffer's data. New externals should uses these instead of accessing the data array directly, because with newer PDs that doesn't work. I've also updated the buffer1 example to use the new API wrappers. The issue is that arrays in PD are of type t_word, which is a union that can contain a variety of data, including pointers. In 32-bit architectures you can pretty much ignore that it's a union because floats and pointers are the same size, but on 64-bit architectures it's important to use the w_float member of the union to access stored floats. This patch shouldn't break any old externals unless they're used with PD 0.41 (but then they'd be broken, anyways). I don't have access to an OS X machine or Max/MSP, so I've so far only tested this on 64-bit linux/PD. YMMV. Can someone explain to me why pd's arrays are arrays of t_word instead of t_sample? -s- On Thu, Oct 1, 2009 at 10:41 AM, dmotd dm...@gmx.net wrote: hi spencer, afaik there hasn't been any progress with the 64bit translation, i was going to attempt it last time i needed it but got distracted along the way - and i sent a similar message to thomas at the time, so its going to be on his todo list, but proabably not a priority. i'd be happy to test any changes you make, and collaborate time permitted. ciao, dmotd Spencer Russell wrote: Thought this should probably go to the list: -- Forwarded message -- From: Spencer Russell spencer.f.russ...@gmail.com Date: Tue, Sep 29, 2009 at 11:13 AM Subject: Re: fixing Flext for 64-bit? To: Thomas Grill g...@g.org Am 29.09.2009 um 15:00 schrieb Spencer Russell: Hi Thomas, I'm writing a Flext external to implement Iannis Xenakis's Dynamic Stochastic Synthesis, and running into some problems with buffer handling on my 64-bit system. It seems that currently flext uses the deprecated garray_getfloatarray() function and t_sample arrays, instead of the new garray_getfloatwords() function with t_word unions. Changing the code would make flext incompatible with older versions of PD, but some other external developers are currently using an #ifdef workaround to change to the newer API call for PD versions that support it. I was going to get in there and see if i can't get it working in the flext code, but I wanted to check with you first to see if you had already done any work on that front. I'll of course send you the diffs if i get it working. Shouldn't be that hard and i think it should really only effect the buffer-handling code, but I don't know the flext codebase that well so there might be some hidden gotchas. -spencer On Tue, Sep 29, 2009 at 9:08 AM, Thomas Grill g...@g.org wrote: Hi Spencer, i know that this is something i should work on, but my schedule is insanely tight and i don't get to it. So, if you can make any contributions and testing on 64-bit systems i'd be very grateful. I'd also go for the Pd API selecton by #ifdef statements. gr~~~ As far as i can tell, PD since 0.41 changed arrays to be arrays of t_words instead of t_samples or t_floats. On 32-bit architectures they're all the same size, but on 64-bit architectures t_word is 64-bit, while t_sample and t_float are still 32-bit. For a normal PD external, it's pretty easy to just modify the external to use t_words, but I'm not sure the best way to modify flext to do this without breaking compatibility for externals. One problem is that when an external calls mybuffer.Data(), what should they receive? if the system is PD newer than 0.41, they should receive a pointer to t_word, but MAX or older PD should receive a pointer to t_sample. The other problem is that accessing an element for newer PD requires accessing the w_float member of the t_word union, but the others just use the element itself. There could be some sort of GetValue() wrapper for buffer elements that could be made cross-platform, but would break compatibility with existing flext externals, so that seems seriously sub-optimal. thoughts? -s- ___ http://g.org/ext/flext flext mailing list fl...@g.org http://www.parasitaere-kapazitaeten.net/mailman/listinfo/flext flext_64-bit.patch___ http://g.org/ext/flext flext mailing list fl...@g.org http://g.org/cgi-bin/mailman/listinfo/flext ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [PD] VASP troubles on extended 0.40.3 - and on 0.41-RC1
Hi Ed, thanks for the feedback. I'll try to fix this as soon as i get to a linux machine. gr~~~ Am 20.05.2009 um 01:05 schrieb Ed Kelly: OK. I tried it before with vanilla, but I was using the same pd/extra directory as pd-extended. Now I have isolated the problem by compiling pd-vanilla in a separate folder, and I've found that there is some clash between Gem and vasp. When I remove the Gem (version 0.90, compiled Oct 8 2008 by iohannes) vasp works fine. No warnings in the Pd window with extended, but in the vanilla Pd with the same externals I get this: libdir loader $Revision: 1.8 $ compiled on May 13 2009 at 12:54:42 compiled against Pd version 0.41.4.extended-rc1 warning: old method 'draw' for class 'primTri' renamed 'draw_aliased' warning: old method 'width' for class 'polygon' renamed 'width_aliased' warning: old method 'draw' for class 'polygon' renamed 'draw_aliased' warning: old method 'draw' for class 'curve3d' renamed 'draw_aliased' warning: old method 'width' for class 'curve' renamed 'width_aliased' warning: old method 'draw' for class 'curve' renamed 'draw_aliased' warning: old method 'open' for class 'pix_movieNEW' renamed 'open_aliased' warning: old method 'img_num' for class 'pix_movieNEW' renamed 'img_num_aliased' warning: old method 'auto' for class 'pix_movieNEW' renamed 'auto_aliased' warning: class 'pix_film' overwritten\; old one renamed 'pix_film_aliased' warning: class 'pix_filmQT' overwritten\; old one renamed 'pix_filmQT_aliased' warning: class 'change' overwritten\; old one renamed 'change_aliased' warning: class 'abs~' overwritten\; old one renamed 'abs~_aliased' GEM: Graphics Environment for Multimedia GEM: ver: 0.90 GEM: compiled: Oct 8 2008 GEM: maintained by IOhannes m zmoelnig GEM: Authors : Mark Danks (original version on irix/windows) GEM:Chris Clepper (macOS-X) GEM:Daniel Heckenberg (windows) GEM:James Tittle (macOS-X) GEM:IOhannes m zmoelnig (linux/windows) libdir_loader: added 'cyclone' to the global objectclass path warning: class 'wrap' overwritten\; old one renamed 'wrap_aliased' warning: class 'abs~' overwritten\; old one renamed 'abs~_aliased' ...some clues maybe? Ed --- On Tue, 19/5/09, Thomas Grill g...@g.org wrote: From: Thomas Grill g...@g.org Subject: Re: [PD-dev] [PD] VASP troubles on extended 0.40.3 - and on 0.41-RC1 To: Ed Kelly morph_2...@yahoo.co.uk Cc: pddev pd-dev@iem.at Date: Tuesday, 19 May, 2009, 8:13 PM Hi Ed, could you also try with vanilla pd? I can't reproduce the problem. gr~~~ Am 14.05.2009 um 22:37 schrieb Ed Kelly: Apologies for posting on the main list first - my mistake! Vasp always crashes PD for me. It happens with any vasp object (inc. all help files) on pd-extended-0.40.3 and pd-extended 0.41.RC1. The terminal window shows watchdog: signaling pd... watchdog: signaling pd... etc after a signal 6 message. but before that the text below appears in the terminal inside which PD is running. I've tried pd-extended-0.40.3 and the new RC1 of pd-extended-0.41.1, and re-compiled vasp several times. The bug persists whether jack is running or not, and whether rt mode is on or off. Some process is aborting inside vasp every time. Here's the detail. Best wishes, Ed Intel dual core, 2Gb, Ubuntu Intrepid. tk scaling is 1.44534291704 *** glibc detected *** /usr/bin/pd: free(): invalid pointer: 0x09edaf14 *** === Backtrace: = /lib/tls/i686/cmov/libc.so.6[0xb7e45454] /lib/tls/i686/cmov/libc.so.6(cfree+0x96)[0xb7e474b6] /usr/lib/pd/extra/vasp.pd_linux(_ZN16flext_root_multidlEPv+0x32) [0xb600b764] /usr/lib/pd/extra/vasp.pd_linux(_ZN11flext_multi8AtomList4FreeEv +0x25)[0xb600b995] /usr/lib/pd/extra/vasp.pd_linux(_ZN11flext_multi8AtomListD0Ev+0x29) [0xb600ba29] /usr/lib/pd/extra/vasp.pd_linux(_ZN9vasp_base9ToOutVaspEiR4Vasp +0x69)[0xb5fe0043] /usr/lib/pd/extra/vasp.pd_linux(_ZN7vasp_tx6m_bangEv+0x61) [0xb5fe00dd] /usr/lib/pd/extra/vasp.pd_linux(_ZN7vasp_op8m_dobangEv+0x5f) [0xb5fdffbf] /usr/lib/pd/extra/vasp.pd_linux(_ZN7vasp_op6m_vaspEiPK5_atom+0x28) [0xb5fdf8d8] /usr/lib/pd/extra/vasp.pd_linux[0xb5fe12b8] /usr/lib/pd/extra/ vasp .pd_linux (_ZN16flext_base_multi10TryMethTagEPNS_4ItemEPK7_symboliPK5_atom +0x1cd)[0xb60127c7] /usr/lib/pd/extra/ vasp.pd_linux(_ZN16flext_base_multi8FindMethEiPK7_symboliPK5_atom +0x6b)[0xb6012971] /usr/lib/pd/extra/ vasp .pd_linux (_ZN16flext_base_multi15CbMethodHandlerEiPK7_symboliPK5_atom+0x43) [0xb6012a9d] /usr/lib/pd/extra/ vasp .pd_linux (_ZN16flext_base_multi11cb_anythingEP9flext_hdrPK7_symboliP5_atom +0x43)[0xb60130b5] /usr/bin/pd(pd_typedmess+0x26b)[0x80afb2b] === Memory map: 08048000-08128000 r-xp 08:15 889688 /usr/bin/pd 08128000-08129000 r--p 000df000 08:15 889688 /usr/bin/pd 08129000-0812a000 rw-p 000e 08:15 889688 /usr/bin/pd 0812a000-0853b000 rw-p 0812a000 00:00 0 09de2000-09edc000
Re: [PD-dev] [PD] VASP troubles on extended 0.40.3 - and on 0.41-RC1
08:15 886902 /usr/lib/libmp3lame.so.0.0.0 b41b7000-b41b9000 rw-p 00042000 08:15 886902 /usr/lib/libmp3lame.so.0.0.0 b41b9000-b41ea000 rw-p b41b9000 00:00 0 b41ea000-b41f5000 r-xp 08:15 887233 /usr/lib/libvorbisenc.so.2.0.3 b41f5000-b41f6000 r--p a000 08:15 887233 /usr/lib/libvorbisenc.so.2.0.3 b41f6000-b42e4000 rw-p b000 08:15 887233 /usr/lib/libvorbisenc.so.2.0.3 b42e4000-b42ff000 r-xp 08:15 887231 /usr/lib/libvorbis.so.0.4.0 b42ff000-b430 r--p 0001a000 08:15 887231 /usr/lib/libvorbis.so.0.4.0 b430-b430e000 rw-p 0001b000 08:15 887231 /usr/lib/libvorbis.so.0.4.0 b430e000-b4357000 r-xp 08:15 887199 /usr/lib/libtheora.so.0.3.3 b4357000-b4359000 rw-p 00049000 08:15 887199 /usr/lib/libtheora.so.0.3.3 b4359000-b43c4000 r-xp 08:15 1076527 /usr/lib/pd/extra/pidip.pd_linux b43c4000-b43c5000 r--p 0006a000 08:15 1076527 /usr/lib/pd/extra/pidip.pd_linux b43c5000-b43c7000 rw-p 0006b000 08:15 1076527 /usr/lib/pd/extra/pidip.pd_linux b43c7000-b43cc000 rw-p b43c7000 00:00 0 b43cc000-b43cd000 ---p b43cc000 00:00 0 b43cd000-b4bcd000 rwxp b43cd000 00:00 0 b4bcd000-b4da r-xp 08:15 886766 /usr/lib/libgsl.so.0.12.0 b4da-b4da9000 rw-p 001d3000 08:15 886766 /usr/lib/libgsl.so.0.12.0 b4da9000-b4de r-xp 08:15 886768 /usr/lib/libgslcblas.so.0.0.0 b4de-b4de2000 rw-p 00036000 08:15 886768 /usr/lib/libgslcblas.so.0.0.0 b4deb000-b4dee000 r-xp 08:15 1076558 /usr/lib/pd/extra/aubio.pd_linux b4dee000-b4def000 rw-p 2000 08:15 1076558 /usr/lib/pd/extra/aubio.pd_linux b4def000-b4e0 r--p 08:15 1017319 /usr/share/fonts/truetype/ttf-bitstream-vera/Vera.ttf b4e0-b4e21000 rw-p b4e0 00:00 0 b4e21000-b4f0 ---p b4e21000 00:00 0 b4f08000-b4f17000 r-xp 08:15 1097766 /lib/libbz2.so.1.0.4 b4f17000-b4f18000 r--p f000 08:15 1097766 /lib/libbz2.so.1.0.4 b4f18000-b4f19000 rw-p 0001 08:15 1097766 /lib/libbz2.so.1.0.4 b4f19000-b4f5b000 r-xp 08:15 1076508 /usr/lib/pd/extra/pdp.pd_linux b4f5b000-b4f5c000 r--p 00041000 08:15 1076508 /usr/lib/pd/extra/pdp.pd_linux b4f5c000-b4f5d000 rw-p 00042000 08:15 1076508 /usr/lib/pd/extra/pdp.pd_linux b4f5dPd: signal 6 watchdog: signaling pd... ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev [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 -- Thomas Grill http://g.org ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] grill svn:externals and anonymous access
Hi all, actually it is supposed to be anonymous... i'll check later why it obviously isn't. gr~~~ 2009/4/12 Hans-Christoph Steiner h...@eds.org: Hey Thomas and fans of svn:externals, If you are going to add an svn:external to the pure-data repository, make sure there is anonymous access. Can we at least agree on that? Currently, running a svn up in pure-data/trunk/externals prompts me for a password which I don't have: Fetching external item into 'grill/wmangle' Authentication realm: https://svn.g.org:443 Subversion repository Password for 'hans': .hc --- Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism. - retired U.S. Army general, William Odom ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev -- Thomas Grill http://g.org ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] 'grill' and svn:externals
Hi, which kind of problems do you encounter with the external links? I only introduced them after having tested the checkout on a couple machines which was completely troublefree. gr~~~ Am 02.04.2009 um 02:52 schrieb Hans-Christoph Steiner: Hey, I just noticed that the 'externals/grill' folder was replaced by svn:externals links. Please do not use svn:externals unless you are willing to support them with the nightly builds. They break the nightly builds because of the various errors and warnings caused by TLS certificates, password prompts, etc. .hc News is what people want to keep hidden and everything else is publicity. - Bill Moyers ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Using PD funcs from inside a threaded external
Hi Ben, if it's just about sending messages to outlets, you could also use a lock-free fifo to queue up the messages (in the second thread) and a timer to send out the elements to the outlets asynchronously (pd thread). That's what flext does internally. gr~~~ Am 19.03.2009 um 17:28 schrieb B. Bogart: Thanks for the comments Tim Mathieu, It seems I have two options: * Not send output to PD (very limited functionality) * Use Tim's suggestion. Mathieu Bouchard wrote: Afaik, this will do the rough equivalent of a [delay 0] across threads, so that your (Ben's) thread's execution is inserted between two t_clock events ([delay], [metro], etc.) Does this mean that rendering/audio in PD will be interrupted during this time of global locking? Ah! I would only need to lock while before I do the PD calls right? Something like: sys_lock(); outlet_symbol(); sys_unlock(); ? Thanks! .b. On Wed, 18 Mar 2009, Tim Blechmann wrote: The problem is that I've approached all the gphoto calling functions the same, but one particular function (listconfig) segfaults when I use PD functions, in particular outlet_symbol(). when calling pd's api functions from a separate thread, make sure to hold the global pd lock ... Yes, sorry, I should have known. This is sys_lock() and sys_unlock() if pd is compiled with THREAD_LOCKING enabled. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Accessing Gem_State pointer from a flext-external [resolved]
Hi,
thank, that's valuable feedback... i don't think anyone has used Pd
pointers in flext before.
gr~~~
2009/2/20 Jean-Yves Gratius jygrat...@club.fr:
Hi Thomas,
oups sorry, I forgot to describe my problem.
yes it compiled, didn't crash.
it just sended data that didn't correpond to the gem_state struct.
Indeed i found my error:
I read that gem_state is followed by 2 pointers : gem_state *GemCache
*GemState
If I replace in my code GetPointer(argv[0]) by GetPointer(argv[1]),
everything is ok.
J.Y.
Thomas Grill a écrit :
Hi,
it would be useful to know in which way your code doesn't do what you
want.
Does it compile or not, are there runtime problems, does it crash?
gr~~~
Am 19.02.2009 um 14:25 schrieb Jean-Yves Gratius:
Hi,
I'm triing to write a flext external thats reads a gem_state struct.
I 'd like to access the pixBlock data.
I wrote the following method ( registered as
FLEXT_ADDMETHOD_(0,gem_state, gem_state))
I don't know where I am wrong in my code
any hint ?
thanks,
Jean-Yves
void my_flext_external::gem_state(int argc, t_atom *argv)
{
GemState *my_pointer;
if (CanbePointer(argv[0]))
{
my_pointer = (GemState *) GetPointer(argv[0]); // retrieve
gem pointer
if (!my_pointer)
{ post (no pixblock !); return; }
else
{ //accessing to fields
post (dirty field = %d, my_pointer-dirty);
post (inDisplayList field = %d,
my_pointer-inDisplayList);
post (lighting field = %d, my_pointer-lighting);
post (texture field = %d, my_pointer-texture);
post (*image field = %d, my_pointer-image);
post (*texCoords field = %d, my_pointer-texCoords);
post (multiTexUnits field = %d,
my_pointer-multiTexUnits);
// etc...
}
}
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
No virus found in this incoming message.
Checked by AVG - www.avg.com Version: 8.0.237 / Virus Database:
270.11.1/1960 - Release Date: 02/19/09 10:48:00
--
Thomas Grill
http://g.org
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Accessing Gem_State pointer from a flext-external [resolved]
2009/2/20 marius schebella marius.schebe...@gmail.com: so this means, I can write gem externals using flext? are there examples/documentation around? I'd think that you just have to include the relevant GEM header files to know what's behind the pointers. I'm not sure however whether you need to access functionality that is inside the GEM library and which is not exported. That would be a problem. gr~~~ ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Accessing Gem_State pointer from a flext-external
Hi,
it would be useful to know in which way your code doesn't do what you
want.
Does it compile or not, are there runtime problems, does it crash?
gr~~~
Am 19.02.2009 um 14:25 schrieb Jean-Yves Gratius:
Hi,
I'm triing to write a flext external thats reads a gem_state struct.
I 'd like to access the pixBlock data.
I wrote the following method ( registered as
FLEXT_ADDMETHOD_(0,gem_state, gem_state))
I don't know where I am wrong in my code
any hint ?
thanks,
Jean-Yves
void my_flext_external::gem_state(int argc, t_atom *argv)
{
GemState *my_pointer;
if (CanbePointer(argv[0]))
{
my_pointer = (GemState *) GetPointer(argv[0]); // retrieve
gem pointer
if (!my_pointer)
{ post (no pixblock !); return; }
else
{ //accessing to fields
post (dirty field = %d, my_pointer-dirty);
post (inDisplayList field = %d,
my_pointer-inDisplayList);
post (lighting field = %d, my_pointer-lighting);
post (texture field = %d, my_pointer-texture);
post (*image field = %d, my_pointer-image);
post (*texCoords field = %d, my_pointer-texCoords);
post (multiTexUnits field = %d,
my_pointer-multiTexUnits);
// etc...
}
}
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] compiling external for pd-extended 0.40.3 + flext (windowsXP)
Am 10.02.2009 um 23:51 schrieb Jean-Yves Gratius: Meanwhile, i did'nt succeeded in building latest flext from svn (flpushns.h and flpopns.h not found) Should have been fixed in the meantime! gr~~~ ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] flext / py - autobuild
Hi,
i think i posted this already... it's becoming an FAQ
The puredata svn doesn't currently mirror my sources which means that
those are outdated.
Grab the sources from
https://svn.g.org/ext/trunk/flext
https://svn.g.org/ext/trunk/py
etc.
gr~~~
Am 14.07.2008 um 23:28 schrieb patrick:
hi,
using the autobuild with pd version 0.42 (how can it be (good
news)) and
installing flext successfully, i cannot compile py against python 2.5
using this config.txt:
# what is the base prefix of the Python installation?
PYTHONPREFIX=/usr
# which Python version do you want to compile against?
PYTHONVERSION=2.5
# uncomment if numpy/numarray/numeric support should be compiled in
# for info see http://numeric.scipy.org
#PY_NUMPY=1
#PY_NUMARRAY=1
#PY_NUMERIC=1
# use thread-safe GIL functionality (do this for python version =
2.3!)
PY_USE_GIL=1
# use inofficial (pure data) functionality
# PY_USE_INOFFICIAL=1
doing bash ../flext/build.sh
bash ../flext/build.sh pd gcc
make -f ../flext/buildsys/gnumake-sub.mak PLATFORM=lnx RTSYS=pd
COMPILER=gcc BUILDPATH=../flext/buildsys/ PKGINFO=package.txt
BUILDCLASS=ext USRCONFIG=config.txt USRMAKE=build/gnumake-lnx-gcc.inc
TARGETMODE=release TARGETTYPE=multi THREADED=1 _build_
make[1]: Entering directory `/home/pat/src/pure-data/externals/
grill/py'
mkdir -p pd-linux/release-multi/
g++ -c -msse -mfpmath=sse -ffast-math -O3 -march=pentium4 -pthread -
fPIC
-DPY_EXPORTS -DPY_USE_GIL -DNDEBUG -DFLEXT_THREADS -DFLEXT_SYS=2 -DPD
-I/usr/include/python2.5 -I/usr/local/src/pd/src
-I/usr/local/include/stk -I/usr/local/include/sndobj
-I/usr/local/include/flext source/main.cpp -o
pd-linux/release-multi/main.opp
In file included from source/pybase.h:16,
from source/main.cpp:13:
source/main.h:34: error: expected class-name before ‘{’ token
In file included from source/main.cpp:13:
/usr/local/include/flext/flcontainers.h: In member function ‘void
TypedFifoT::Put(T*) [with T = FifoEl]’:
source/pybase.h:181: instantiated from here
/usr/local/include/flext/flcontainers.h:456: error: no matching
function
for call to ‘TypedFifoFifoEl::Put(FifoEl*)’
/usr/local/include/flext/flcontainers.h:405: note: candidates are:
void
Fifo::Put(Lifo::Cell*)
/usr/local/include/flext/flcontainers.h: In member function ‘T*
TypedLifoT::Pop() [with T = FifoEl]’:
/usr/local/include/flext/flcontainers.h:466: instantiated from ‘T*
PooledFifoT, M, O::New() [with T = FifoEl, int M = 2, int O = 1]’
source/pybase.h:179: instantiated from here
/usr/local/include/flext/flcontainers.h:380: error: invalid
static_cast
from type ‘Lifo::Cell*’ to type ‘FifoEl*’
make[1]: *** [pd-linux/release-multi/main.opp] Error 1
make[1]: Leaving directory `/home/pat/src/pure-data/externals/grill/
py'
make: *** [build-release-multi] Error 2
knowing that i run linux / 32 bits / intel and that i use python 2.5
would it be possible to use a compiled version of a friend? of maybe
thomas if you have the time to help me with this.
thanks!!
pat
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
smime.p7s
Description: S/MIME cryptographic signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] sms pd external - design choices
Am 10.07.2008 um 19:35 schrieb Rich E: I see that [pool] has the ability to share a data space among different buffers by taking a name as its first argument. I am digging through its code right now, but am not familiar with the flext API. I don't yet see how it manages to allow different [pool]'s to share the same data. Data sharing in pool is no flext-specific feature... you can do that with any external by making the shared data static (in c-style9, as opposed to be allocated with the object instances. gr~~~ smime.p7s Description: S/MIME cryptographic signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] compiling FLEXT vst~ on Macintosh
Hi Miller, many thanks for the contribution - I think that a lot of people will be happy about it. I can't say if it makes sense to keep compatibility with Carbon plugins - considering that they have never really worked with vst~. Also when i was working on the Mac code of vst~ the main problem was the editor window - i can't really remember but there must still be some code missing to actually handle user interaction (in editormac.hpp). all the best, Thomas Am 07.07.2008 um 22:17 schrieb Miller Puckette: Hi all, For a music production I had to compile vst~ for OSX in Flext. I noticed that there is already code in vsthost.cpp that seems to try to load vst plug-ins in the form of carbon code resources (search for FSPathMakeFSSpec) but I found no compiled vst~ in Pd-extended, nor does anyone on the list seem to think this exists. I adapted the code so that it loads macho vst plug-ins. It seems to work, except that, in the help patch, when I try to open the editing window nothing comes up. I suspect this has to do with something other than vst~ proper but haven't looked into it since I don't know how the editor stuff is supposed to work. Before I go on and submit this as a formal patch, I'd like to know if anyone knows whether the carbon code should be kept around (do there still exist vst plugins in carbon taht are worth trying to support?) and whether I should look harder to figure out why the editing window in the help file doesn't open. For anyone curious, grab the patch (vst-OSX.patch) and/or the cmopiled extern (vst~.pd_darwin) from http://crca.ucsd.edu/~msp/tmp/ . cheers Miller ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev Thomas Grill http://g.org smime.p7s Description: S/MIME cryptographic signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Reliable MIDI library for Windows?
Hi David, the devel_0_39 branch of pure data completely relies on PortMidi for all platforms. We (the vibrez team) found that to work perfectly also for sysex, realtime etc. messages under Windows. It's fairly easy to provide a patch for vanilla PD, provided one has got time and interest. gr~~~ Am 26.06.2008 um 08:35 schrieb PSPunch: Hi, I understand that MIDI objects under Windows is said to be less stable than Linux, due to the MIDI functions under Windows API that Pd relies on. If I were to write my own MIDI I/O external for Windows, are there such things as alternative MIDI libraries or APIs available, or does Windows not allow you to access MIDI devices it recognizes without running data through its interface? Like some posts I made about a month back, my initial goal is to get raw MIDI inout working, this time on Windows. Any hints appreciated. Thanks. -- David Shimamoto ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev Thomas Grill http://g.org smime.p7s Description: S/MIME cryptographic signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Reliable MIDI library for Windows?
Am 01.07.2008 um 14:21 schrieb PSPunch: Did not quite catch up on weather you meant that the PortMidi libraries should work as is, or needs a simple patch applied. portmidi is fine as it is In any case, yes, I do have the interest.. and time, perhaps I can manage. Is this literally a patch to be applied to the source? the change for vanilla pd (or pd-extended) is not just a patch. This potential patch can be deduced from the modifications that have been made in devel_0_39, though. I do mainly work on pd-extended, and building either distros, I have not been very successful under windows. I am certainly sure I will learn something from it. It's easiest to start with Miller's pd which should be possible to build under Windows. A patch for Miller's pd should also work for pd-extended. gr~~~ -- Thomas Grill http://g.org smime.p7s Description: S/MIME cryptographic signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] block~-overlapped canvases: samplerate wrong for dsp objects
Am 28.06.2008 um 11:50 schrieb IOhannes m zmölnig: Thomas Grill wrote: Hi, I consider that a bug and would file a bug report, but since this must have been present for a long time and must surely have been discovered by other people as well it might also be a feature any ideas? my personal explanation for this was always, that the samplerate really means datarate; since you get the double amount of samples in the same time, the doubled samplerate is somewhat understandable (though unexpected). while it is understandable from a developer's perspective it's certainly a bug from the user's point of view, no? (given that sample- rate-sensitive objects behave wrong) For osc~ it's possible to correct the frequency by using the reblocking parameters, but that not the case for more complicated objects. I'll file a bug report gr~~~ smime.p7s Description: S/MIME cryptographic signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] block~-overlapped canvases: samplerate wrong for dsp objects
Hi, i just stumbled over a strange behavior in canvases with overlapped blocks without resampling (e.g. set with [block~ 1024 2]). In such canvases e.g. [osc~ 440] delivers a cosine wave with an actual frequency of 220 Hz, because of the double overlap. This is because dsp signal vectors carry the wrong sample rate (sp[0]- s_sr = 88200 instead of 44100). [samplerate~] correctly reports 44100 because it uses a different method of retrieving the sample rate. I consider that a bug and would file a bug report, but since this must have been present for a long time and must surely have been discovered by other people as well it might also be a feature any ideas? gr~~~ smime.p7s Description: S/MIME cryptographic signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] What goes on during dsp ticks?
Hi David,
Am 14.06.2008 um 03:08 schrieb PSPunch:
=
== PROCESS BLOCK.2 ==
=
while (n--) {
// *out++ = *in++;
}
Remarks: Action is commented out but signal goes through.. Why?
that's because in and out can point to the same memory... signal
vectors are reused in PD for cache-friendlyness.
=
== PROCESS BLOCK.4 ==
=
n--;
*out++ = 0;
while (n--) {
*out++ = *in++;
}
Remarks: Expecting first sample of the block to be zero and others
delayed by 1 sample. Instead, I get an constant output of zero.
As above... you have to be aware that when you are writing to the
output, you change the input.
Either cache the input or use a different algorithm (in this case
start from the end)
gr~~~
smime.p7s
Description: S/MIME cryptographic signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Resolved :: Pool disappearing or not getting created
Hi Ben, many thanks for your findings! I'm still not finished with the autoconf stuff, mainly because of problems on OSX 10.4, but let's hope the integration into pd-extended will make such issues vanish. gr~~~ Am 11.04.2008 um 20:21 schrieb B. Bogart: Hello all, Thomas in particular. This is really for the archives as the disapearing pool problem was resolved, and that is probably the same cause of pool not getting created in SVN flext. Let this be a lesson, when a flext external acts funny, recompile them all from the same flext!!! I've been using pool just to store the results of some SOM training data, and I'm bizzarly stuck. I was working on a patch a month ago, all was well, then I recently opened the same patch, and the pool objects were not visible. I did not change anything on the system, no updates, same version of PD (0.39-2), same flext and same pool. I've tried a bunch of stuff to resolve this but I've not gotten any ware. I'll start with my most recent efforts. I've removed all files in /usr and /usr/local with flext in the same, including directories. Then I build flext from SVN (trunk revision 9690 for the flext directory) I commented out SIMD=1 to turn off SSE for this AMD64. in config.txt I added the proper paths to config-lnx-pd-gcc.txt to PD sources, made the flext path /usr/local, the outpath=. , installpath /usr/lib/pd/extra, commented out all the STK and SndObj stuff. removed all sse UFLAGS, leaving only -ffast-math left other flags to default. Compiling flext and pool, after build.sh pd gcc clean, seems to work fine, I see the binaries, I'm using -lib pool to load pool. (after pd gcc install for both flext and pool) PD says pool is loaded: pool 0.2.2pre - hierarchical storage object, (C)2002-2008 Thomas Grill but the pool object will not instantiate, (just the dashed line border) and the usual console message: pool ... couldn't create pool test ... couldn't create Does the current SVN version of flext/pool still play with 39-2 or only newer PDs? (I'm using the old PD as I know its rock stable for this installation). So I've downloaded the stable flext and pool from thomas website, and trying again: copied the same config-lnx-pd-gcc.txt and config.txt from the SVN build. starting pd again with -lib pool PD says pool is loaded: pool 0.2.1 - hierarchical storage object, (C)2002-2005 Thomas Grill making a pool object does instantiate, but is invisible. I can blindly click on it to get the pool properties, and connect things to it, but can't see the object itself. Ok, so tried removing the .pdsettings, and not using -lib pool, and creating a pool object, and it works! So I'll put the pdsettings back in lib by lib to see if I can figure out what library its conflicting with. Ok, it was (duh) xsample that was left over from some old flext was causing the invisible pool problem. Having -lib xsample messed with pool. I'm sending this message just for the archives. .b. ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [flext] Compiling Audition Library in Mac OS 10.5
Hi Julian, i don't know audition but i'm suspicious about the uppercase Audition_setup... have you tried to create the audition object lowercase? gr~~~ Am 26.03.2008 um 18:58 schrieb Julian Villegas: Hi, I managed to compiled the Audition library (http://lumiere.ens.fr/ Audition/tools/realtime/) in my MacBook using the last version of Flext (checked out from the sv server). The compilation was done as indicated in the readme file of the Flext distribution, and there were no errors. The library was installed in the Extra directory in Pd (v 0.41.2). Also, I added 'Audition' in the startup preferences menu. I know that flext is working cause I could compile and use xsample, but when I try to use Audition, I have the following error: load_object: Symbol Audition_setup not found I know that some of you have had that dreadful message before and I was hoping you could help me with this. Thanks in advance, Julian Villegas Me pregunto de un modo pensativo Que significa ser Colombiano? No se le respondi. Es un acto de fe JLB. Looking for last minute shopping deals? Find them fast with Yahoo! Search. ___ http://g.org/ext/flext flext mailing list [EMAIL PROTECTED] http://www.parasitaere-kapazitaeten.net/mailman/listinfo/flext smime.p7s Description: S/MIME cryptographic signature ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] grill/py with python 2.5
Hi Pat,
are you using the latest CVS versions of both flext and py?
If not, please try that.
gr~~~
Am 14.02.2008 um 07:15 schrieb patrick:
i cannot compile py against python 2.5 on linux:
bash ../flext/build.sh pd gcc
make -f ../flext/buildsys/gnumake-sub.mak PLATFORM=lnx RTSYS=pd
COMPILER=gcc BUILDPATH=../flext/buildsys/ PKGINFO=package.txt
BUILDCLASS=ext USRCONFIG=config.txt USRMAKE=build/gnumake-lnx-gcc.inc
TARGETMODE=release TARGETTYPE=multi THREADED=1 _build_
make[1]: Entering directory
`/home/pat/src/pdmtlpd/pure-data/trunk/externals/grill/py'
mkdir -p pd-linux/release-multi/
g++ -c -msse -mfpmath=sse -ffast-math -O3 -march=pentium4 -pthread -
fPIC
-DPY_EXPORTS -DPY_USE_GIL -DNDEBUG -DFLEXT_THREADS -DFLEXT_SYS=2 -DPD
-I/usr/include/python2.5 -I/home/pat/src/pdmtlpd/pure-data/trunk/pd/
src
-I/usr/local/include/stk -I/usr/local/include/sndobj
-I/usr/local/include/flext source/main.cpp -o
pd-linux/release-multi/main.opp
source/main.h:34: error: expected class-name before ‘{’ token
/usr/local/include/flext/flcontainers.h: In member function ‘void
TypedFifoT::Put(T*) [with T = FifoEl]’:
source/pybase.h:181: instantiated from here
/usr/local/include/flext/flcontainers.h:456: error: no matching
function
for call to ‘TypedFifoFifoEl::Put(FifoEl*)’
/usr/local/include/flext/flcontainers.h:405: note: candidates are:
void
Fifo::Put(Lifo::Cell*)
/usr/local/include/flext/flcontainers.h: In member function ‘T*
TypedLifoT::Pop() [with T = FifoEl]’:
/usr/local/include/flext/flcontainers.h:466: instantiated from ‘T*
PooledFifoT, M, O::New() [with T = FifoEl, int M = 2, int O = 1]’
source/pybase.h:179: instantiated from here
/usr/local/include/flext/flcontainers.h:380: error: invalid
static_cast
from type ‘Lifo::Cell*’ to type ‘FifoEl*’
make[1]: *** [pd-linux/release-multi/main.opp] Error 1
make[1]: Leaving directory
`/home/pat/src/pdmtlpd/pure-data/trunk/externals/grill/py'
make: *** [build-release-multi] Error 2
it worked some months ago. my setup is almost the same (ubuntu 7.10).
pat
___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
smime.p7s
Description: S/MIME cryptographic signature
___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pyx shell replacement
Hi Ben, Is there any flext/pyx magic for converting from python types to PD types? The way I'm using shell has two cases: 1. it only returns a single number (cpu or memory usage) 2. it executes an xset command, and does not care about output. So for now I'm assuming these cases. Ideally it would be nice if a command output this: 0 10 0.3 then outlet would send a list of three floats. 0 dog as a message of a float and a symbol etc.. this is done exactly like this by the py/pyext external. Attached is a patch and a script that can act as a shell replacement. gr~~~ shell-test.pd Description: Binary data import os,pyext def shell(*args): s = .join(map(str,args)) f = os.popen(s) r = f.read().split() f.close() return r class shellx(pyext._class): def _anything_1(self,*args): s = .join(map(str,args)) f = os.popen(s) for fi in f.readlines(): self._outlet(1,fi.split()) f.close() self._outlet(2) smime.p7s Description: S/MIME cryptographic signature ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pyx shell replacement
Am 29.01.2008 um 00:20 schrieb Thomas Grill: Hi, I figured something that runs os.system() on an arbitrary string would be a good enough start, though coercing the _anything_ *args into a string seems to be challenging me. do you mean .join(map(str,*args)) ? no sorry, if args is a sequence i think you rather mean os.system( .join(map(str,args))) In this case the arguments are separated by spaces. gr~~~ -- Thomas Grill http://g.org smime.p7s Description: S/MIME cryptographic signature ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Is this possible - List input to inlets other than the leftmost...
Mike McGonagle schrieb: From reading some of the docs, I got the impression that it is NOT possible to have any subsequent inlets allow for list input? Is this correct? Do you know why this is? I have some ideas that I would like to implement with lists on the second and third inlets... You could use flext where this is automatically dealt with. gr~~~ ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Connecting up an SQL Database to PD
Tim Boykett schrieb: Hi, this is interesting because I am fiddling about with exactly these sorts of things at precisely this moment. There was the claim recently that an external was not necessary because pyext exists and SQL stuff can be done in python. However my experience in getting pyext to work has been negative. However I have happily made an external python program talk to a SQL database as well as speaking OSC to talk with PD and Max and many other things. What exactly was your problem with pyext? greetings, Thomas ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] stuff missing from pd-extended (flext please)
B. Bogart schrieb: Thomas, Any progress on flext in pd-extended? Hey Ben, i'm really sorry about that, but again i have so many urgent things to do that i can't even think about that in the next time. I'm afraid someone else has to do it - is there still a chance to get some grants for it? As already stated, building flext or flext-based externals is really easy using a usual makefile, the complicated thing (for me at least) is the integration into the pd-extended build system, although H.C. might say it's not. If someone volunteers to do it i'm glad to answer any related questions. greetings, Thomas ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] repository layout
Hi, sounds very reasonable to me. The only potential problem that i see is the flat hierarchy (resp. naming scheme) of the branches and tags. It seems that this folder would populate quite fast and might quickly become a mess. On the other hand it's quite easy to clean it up again with svn ;-) Btw., where would the svn repository be located? greetings, Thomas Am 11.09.2007 um 16:35 schrieb IOhannes m zmoelnig: hi. after the talk about svn at the pd-con, it seems like there is a general ok from the community, if somebody would be willing to perform the actual migration. actually i could be this volunteer. ad miller: there exist migration paths from both cvs and svn to git, so svn would do no harm before we can switch to git :-) about the structure: i have written down some ideas on how an svn-repository could be structured at http://puredata.info/Members/zmoelnig/pdcon07/SubVersion basically the layout keeps the same, but with svn-specifics like meta-directories trunk, tags and branches. ideally (for me) the layout of trunk would be: /trunk/pd/ /trunk/pd-devel/ /trunk/desiredata/ /trunk/externals/ /trunk/packages/ /trunk/scripts/ /trunk/doc/ differences to the current layout are: - moved abstractionsextensionsxguiFramestein into externals - desiredatapd-devel live beside pd (not in a separate branch) - htdocs is deprecated (but could as well move into doc) - supercollider has moved into scripts (i am not sure about this, but it seems to be the best place, since bash_completion is already in there; supercollider is no external, it is rather a set of sc3- scripts to ease the use of pdsc together) the layout of tags would be: /tags/pd-0.40-4/ /tags/pd-0.41-1/ /tags/desiredata-0.39-1/ /tags/zexy-2.1/ /tags/pd-extended-0.39.2-rc1 ... (that is: a _very_ flat structure of released code) the layout of branches would be almost the same as that of tags (but tagged revisions should not be touched any more, whereas branched revisions can be bug-fixed...) both branches/tags should only be used for: - releases (+maintenance) - legacy (discontinued) projects it is my believe that tagsbranches should mainly be used for people who want to checkout working code (!), rather than developers who want to try something out without interfering with the existing code-base (trunk) for quick experimental branches (e.g. if you want to implement a feature but do not want to spill the trunk), i would suggest a 4th meta-directory experimental, like: /experimental/pd-0.40-kiosk/ /experimental/pd-extended-0.39-newbuildsystem/ projects in experimental are not meant to be continued, but their changes should go back into the main trunk (either by merging into the original project or by living besides it) in any case, these experimental branches should be deleted when finished, in order to keep the directory-layour reasonably small. comments are highly welcome fgmasd.r IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] repository layout
Am 11.09.2007 um 17:04 schrieb IOhannes m zmoelnig: Thomas Grill wrote: Hi, sounds very reasonable to me. The only potential problem that i see is the flat hierarchy (resp. naming scheme) of the branches and tags. It seems that this folder would populate quite fast and might quickly become a mess. On the true. a better idea would probably be that each package gets its folder where releases can be put into, e.g.: /tags/zexy/zexy-2.1/ the reason for the flat hierarchy was, that deep hirarchies often tend to confuse more than not, at least if several unorganized people are involved (like we are): while more scrolling is involved in the flat hierarchy (seemingly more of a mess), inhierarchical structures it might eventually turn out that we have /tags/foo-1.0 but /tags/externals/bar/bar-2.0, which makes bar-2.0 much harder to find in relation to foo-1.0 Clearly the hierarchy should be as shallow as possible, on the other hand i always like the idea of sandboxes where each of the unorganized people can mess around on a micro-scale, while it stays macroscopically organized. Tags and branches like /tags/project/project-0.0 seem to be a good compromise. Btw., where would the svn repository be located? i think there are currently no real objections against staying at sourceforge (at least, i had planned to put it there; just for the sake of all the developers already having an account there (and knowing their passwords)) True, sounds good. greetings, Thomas ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] repository layout
Am 11.09.2007 um 19:58 schrieb Mathieu Bouchard: - desiredatapd-devel live beside pd (not in a separate branch) If Thomas hasn't changed his mind, pd-devel is going to be obsolete soon. The latest changes still have to be picked up from there and moved somewhere else, such as sf.net patchtracker and the desiredata branch, but for all practical purposes, there will be no such branch. Let me also say that pd-devel very much deserves to be a branch (rather than a plain folder) because it has rather high mergeability with Miller's branch. No, i haven't, but i have no idea how long it will take to extract all of the good ideas in pd-devel and make patches for that. Right now i haven't had time to only make a single one, although that will most likely change soon. I'm not sure whether it's better to have pd-devel as a stand-alone project or let it be a branch... it doesn't seems to really matter. About the mergeability i'm not so positive... i'm afraid the only way to really promote the change to pd-main is to hand-craft the patches. greetings, Thomas ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] sys_idlehook and audio API interaction
Hi Claude, since we were in the same paper session at the convention you might remember that i was advocating a different idle processing scheme in my talk. When you are looking into m_sched.c you'll notice that the sys_idlehook call is dependent on the didsomething varialbe, which is again dependent on the behavior (type, blocksize etc.) of the specific audio api. I haven't had time to provide patches for the devel_0_39 solution to this, but i'll promise that i'll do one of these days. greetings, Thomas Am 05.09.2007 um 20:48 schrieb Claude Heiland-Allen: Hi, I made an external to let patches do things when Pd is idle: [idlebang] -- output a bang when Pd is idle but it seems to be heavily dependent on the audio API. With OSS, I get around 200 bangs per second. With ALSA, I get around 7 bangs per second. With JACK, I get around 1 bang per second. With audio off, I get around 16 bangs per second. I haven't tried PortAudio yet. Any idea why this might be? Source code tarball is here: https://devel.goto10.org/dl.php?repname=maximuspath=%2Fidlebang% 2Frev=0isdir=1 Thanks for any insights, Claude -- http://claudiusmaximus.goto10.org ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] sys_idlehook and audio API interaction
Am 05.09.2007 um 22:04 schrieb Claude Heiland-Allen: Yes, I remember, with different return codes from the hook for I'm done and I have more to do (and also I did nothing?). I also think there should be a better mechanism for registering hooks, that also allows unregistering hooks later. Example: 1. X stores existing loader hook W, registers hook X 2. Y stores existing loader hook X, registers hook Y 3. X wants to remove hook, so restores loader hook to W 4. Y no longer has its hook registered = badness In Miller's pd the sys_idlehook is meant to be modified primarily on class setup - unregistering is not possible as you outlined. In the devel branch, there's a threadsafe sys_callback function to do this. Return value 0 (i'm done) for a registered idle callback function would unregister the hook. Have a look at our paper on your pdconf usb stick. Something like a priority queue of hooks would be useful, but then you're in the realm of implementing a multitasking scheduler It's not undoable but then again it might be more useful to use separate threads with adjustable priorities and use fifo queues and idle processing for communication with the pd kernel. That's how it is done in vibrez. greetings, Thomas ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pd cvs write access
Hi Nathaniel, please have a look at the devel_0_39 branch before committing your changes - maybe your fixes are already tackled there. I fixed midi input a long while ago, including sysex, real time and system common messages. greetings, Thomas Am 16.07.2007 um 16:12 schrieb nathaniel dose: Can someone please give me write privileges to CVS? (sourceforge username: dosena2) I have some updates for pd/src and pd/portmidi that provide support for sysex on OS X. The changes are extremely local in the sense that only a few lines of code are changed in each of 3 files. regards -- We've Got Your Name at http://www.mail.com! Get a FREE E-mail Account Today - Choose From 100+ Domains ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pd cvs write access
FYI, I just realized that i only fixed the portmidi implementation, because that's all really needed. Am 16.07.2007 um 19:59 schrieb Thomas Grill: Hi Nathaniel, please have a look at the devel_0_39 branch before committing your changes - maybe your fixes are already tackled there. I fixed midi input a long while ago, including sysex, real time and system common messages. greetings, Thomas Am 16.07.2007 um 16:12 schrieb nathaniel dose: Can someone please give me write privileges to CVS? (sourceforge username: dosena2) I have some updates for pd/src and pd/portmidi that provide support for sysex on OS X. The changes are extremely local in the sense that only a few lines of code are changed in each of 3 files. regards -- We've Got Your Name at http://www.mail.com! Get a FREE E-mail Account Today - Choose From 100+ Domains ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] cleanup of CVS
Hi all, seems like the s-abstraction folder has already been checked in, because now all the .svn subfolders are in the CVS... that's not exactly what was intended, i guess. greetings, Thomas Hans-Christoph Steiner schrieb: On Jul 9, 2007, at 11:25 PM, Chris McCormick wrote: On Mon, Jul 09, 2007 at 07:49:29AM -0400, Hans-Christoph Steiner wrote: Well as it stands now I'd have the annoying requirement that I keep two local copies of s-abstractions and have to manually port changes between them and commit to two different repositories, which was the reason for my original post. If you are going to maintain your code in a repository that is different from the pure-data one, then it makes the most sense to only import releases into the pure-data CVS, instead of keeping it synced. cvs import allows you to do this with one command that also makes a tag for that release. Ok, I'm convinced. I haven't used CVS import like that before; I wonder if you could point me to some docs on that, or give me an example. Would it be something like: export [EMAIL PROTECTED]:/cvsroot/pure-data cvs login cvs import s-abstractions/ More like this: export CVSROOT=:ext:[EMAIL PROTECTED]:/cvsroot/ pure-data export CVS_RSH=ssh cd s-abstractions cvs import abstractions/s-abstractions CHR15M S-ABSTRACTIONS_0_2 It goes like this: cvs import repository vendor-tag release-tags... repository - the full path to the spot in the CVS repository where this stuff will go. This could be instead: externals/s-abstractions, abstractions/chr15m/s-abstractions, etc. etc. vendor-tag - whatever tag you want for yourself, standardized to UPPERCASE release-tags - a tag for the library and version that you are importing (multiple if you want, only one required) .hc Best, Chris. --- http://mccormick.cx I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr. ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd+programming language
Am 04.07.2007 um 23:37 schrieb ruben gomez: I try py/pyex but not work with the python interpreter. The module pyex make error. Which operating system, which version of py/pyext, which version of pd, which version of Python, which exact error message? Can you provide an example patcher where this happens? greetings, Thomas ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] calling a function
Hi Alain,
are you sure that funct indeed points to an instance of your class?
In other words, have you done something like x-funct = new Test;
before?
greetings,
Thomas
Am 15.06.2007 um 18:57 schrieb [EMAIL PROTECTED]
[EMAIL PROTECTED]:
I'm having problems calling functions and I'm currious if I a doing
it the right way. I a writing the
external in c++. I make a class Test and I declare a function for
example:
void Test::post_filepath(char* path) {post( opening %s, path);}
Then within the externals typedef stucture I include a pointer to
the class for example:
typedef struct _myexternal {
t_object x_obj;
Test *funct;
} t_myexternal;
When I call the function like this:
void capture_cap(t_myexternal *x, t_symbol *file) {x-funct-
post_filepath(file-s_name);}
Pd crashes, I have to do it like this to avoid a crash:
void capture_cap(t_myexternal *x, t_symbol *file) {post( opening %
s, file-s_name);}
what am I doing wrong and what is the proper way to do it?
Thanks,
Alain
___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] list-emath
Hi Frank, same in list-math, i guess. all the best, Thomas is there a good reason why in list-emath there is [expr $f1 $1 $f2] instead of just [$1]? No good reason, it's just historical. I guess the latter would be even more flexible. Yep, I'll change it. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev Thomas Grill http://g.org ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] list-emath
Hi Frank, is there a good reason why in list-emath there is [expr $f1 $1 $f2] instead of just [$1]? I guess the latter would be even more flexible. greetings, Thomas -- Thomas Grill http://g.org ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] sysloader problem
Hi, it's true that the current loader hook has designed for libs only. I've also thought about introducing an additional object loader, which should then also be able to draw its patcher text from an external source (like from the web, or from a database), but that's hard because of the way how pd currently loads and creates the objects. oops, wanted to write more, but no time all the best, Thomas IOhannes m zmoelnig schrieb: hi miller, all. i am currently having troubles implementing the hexloader as a system-loader. while things work rather straightforward in external/library land, it stops being trivial when it comes to loading abstractions via a system-loader. (this is needed since the hexloader mainly applies a different objectname-filename mapping, which should eventually work for abstractions too) the problem is, that in the context of the loader, i have no idea about the arguments for the object instance. unfortunately abstractions do not have the abstract class vs instance separation like binary objects, so the only way to instantiate them seems to be to directly evaluate them with the arguments available in some context. ultimately it would be good if patches would be loaded with the same mechanism as other externals within the pd core (this is: with a separate patch_loader() that is registered just like the lib_loader()) a temporary workaround would be some way to access the arguments passed to a yet-unknown object from within the loaders. mfasd.r IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev -- Thomas Grill http://g.org ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] d_math.c break[s] strict-aliasing rules
code like sqare root or inverse square root can be coded by just utilizing the rsqrtps and sqrtps opcodes, with a 14 bit precision, when working on the sse unit ... 14bit precision would leave a lot to be desired in Pd. Are there high precision operators? From what i recall, the opcodes are meant to be used iteratively (like in root-finding), then yielding full precision. Is complying with -fstrict-aliasing enough to take care of the aliasing issues? Do you have any examples of handling alignment issues? I posted an example of autovectorizing code taking that into account a while ago http://lists.puredata.info/pipermail/pd-dev/2006-11/007880.html greetings, Thomas -- Thomas Grill http://g.org ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] -dynamiclib causes name clashes, was: Re: [PD] msd broken
Hi Marius, I wonder if this is an OSX problem, but my msd2D and msd3D objects are not working (see previour posts). this is almost certainly caused by a conflict of an existing external using an older version of flext. I hope that i now adjusted the flext build system in a way that this doesn't happen anymore. As a note for the devs: It seems that building externals under OSX with --dynamiclib - undefined dynamic_lookup can cause symbol clashes at runtime, while -bundle -bundle_loader $(PDBIN) doesn't. That's why i returned to the old method. Any comments? greetings, Thomas -- Thomas Grill http://g.org ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [ pure-data-Bugs-1518030 ] subpatch clearing itself crashes Pd
Am 11.02.2007 um 21:50 schrieb Tim Blechmann: Well, then how should Pd solve the logical pitfalls in your opinion? mark the object as deletable, if the messaging is happening, wait for the object to return from the message function, then it can be safely deleted. exactly, but the object should not process any further messages when the mark is set. I recently encountered the same situation, and by debugging i found that the crash happens while traversing the outlets to see if the message should be sent to other objects. It would be easy to check for such a mark there. greetings, Thomas ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] string type for pd
Hi Martin, many thanks for your initiative, it is greatly appreciated! It would be extremely useful to also define some API for string handling right from the start, to be able to use the string type in externals... all those functionality that seems to be contained in your str object. best greetings, Thomas PS. It would be good to submit the patch to the sourceforge PD project. Am 27.01.2007 um 17:53 schrieb Martin Peach: I have implemented a string type for Pure Data as well as a [str] object that uses it. For it to work, pd needs to be patched. The [str] is contained in a separate file but the infrastructural changes are part of pd. I have attached a patch file for anyone interested. If it is acceptable, where should I put it? I could check str.c into externals, but it won't build unless the source is patched... The str object can join, split, load, save, drip, compare and convert strings to other types. It should be useful for formatting arbitrary strings for communication via byte-oriented objects such as [comport] and [tcpserver], which can then talk to external hardware (e.g. serial LCD or lanbox), for example terminating strings with CR LF instead of semicolons. Other potential applications of the string type that I haven't yet implemented are math using very long integers and row-by-row image processing. ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] iem16 compilation problem on osx
Hi all, i already submitted patches for this and other issues with IEM sources to the patch tracker a while ago. IEM stuff doesn't correctly deal with Mac/Intel endianness at the moment. greetings, Thomas Am 16.01.2007 um 15:31 schrieb james tittle: On Jan 16, 2007, at 6:46 AM, Georg Holzmann wrote: iem16 does not compile on OSX - the error is before the int32 in the code below: 8---8--- #ifdef __apple__ #define HIOFFSET 0/* word offset to find MSB */ #define LOWOFFSET 1/* word offset to find LSB */ #define int32 int /* a data type that has 32 bits */ #endif /* MACOSX */ ...snip... 8---8--- So maybe this __apple__ is not defined ? should this be defined automatically or otherwise changed to an other define ? ...yep, two things wrong here: it'd be __APPLE__ not __apple__, but in this case I think we need something like __ppc__ jamie ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev Thomas Grill http://g.org ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] iem16 compilation problem on osx
Am 16.01.2007 um 16:13 schrieb Georg Holzmann: Hallo! i already submitted patches for this and other issues with IEM sources to the patch tracker a while ago. IEM stuff doesn't correctly deal with Mac/Intel endianness at the moment. hm ... I can't find that patches (maybe I'm blind ;) ... are you sure that you have submitted them ? http://sourceforge.net/tracker/index.php? func=detailaid=1604140group_id=55736atid=478072 http://sourceforge.net/tracker/index.php? func=detailaid=1604134group_id=55736atid=478072 http://sourceforge.net/tracker/index.php? func=detailaid=1604133group_id=55736atid=478072 -- Thomas Grill http://g.org ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] supporting MSVC6
Am 08.12.2006 um 17:33 schrieb Hans-Christoph Steiner: On Dec 8, 2006, at 3:18 AM, Mathieu Bouchard wrote: On win32, is there any reason for still supporting MSVC6 instead of switching to MinGW and/or Cygwin? Some people have expressed desire to use MSVC, but no one has done the work, so... Personally, I only support MinGW, but I haven't removed any of the MSVC support. What exactly do you mean with no one has done the work? I have been using MSVC 6, since i'm working with PD and i'm still using it, plus, Miller's makefiles for Windows have always been based on MSVC 6. Maybe i don't get it, but what's the point about removing support for that compiler? Of course, i'm not talking about DD. greetings, Thomas -- Thomas Grill http://g.org ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] slowing down dsp function inside perform loop
Hi Eric, i'm wondering how asynchronous DSP works in Max. As far as i know only messaging can be deferred. Is the DSP operation done outside the normal DSP chain or is it some DSP operations on buffer data that you are doing in message callbacks? greetings, Thomas Am 06.12.2006 um 11:37 schrieb Eric Lyon: Thank you Thomas, hc and others for helpful feedback. The function I'm deferring is doing asynchronous DSP, not messaging. Essentially a barrage of intensive DSP thrown at the contents of a buffer (array in Pd land) that will hopefully be done in time to be played back in the main perform loop. Actually a lot of it is working on Pd now, but there are a few functions that do reliably crash Pd, even though they're not CPU-expensive. Quite possibly some memory indiscretion. I'll report back on any further findings. Best, Eric On Dec 5, 2006, at 10:13 PM, Mathieu Bouchard wrote: On Wed, 6 Dec 2006, Thomas Grill wrote: currently there's no low-priority messaging in Miller's pd version, but there is in the devel branch. It's one of the features that have been there for some time and i'm trying to provide a patch for Miller, so that it can make it into vanilla PD some time in the future. Hopefully the auto-discard mechanism of the patch tracker will blow up before that time. Don't expect the feature to be available soon. So, how does one use that feature? Is it that all the audio is high-priority and all the non-audio is low-priority? Isn't that basically the way it is now? Correct me if I am wrong, but isn't audio data processed first in each cycle, then message data? FYI: Max since 4.3 (I believe) has two audio threads, a high priority and a low priority. qelems and the defer() functions give you access to the low priority thread in externals. Another detail of not is that the threads are cooperative, not pre-emptive. If a give process doesn't defer(), then it won't give up that thread until its done processing. .hc ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] audio interruptions from outside events (only with Pd)
Am 04.12.2006 um 15:30 schrieb Hans-Christoph Steiner: We are in the middle of trying to make [hidio] as robust as possible in terms of plugging and unplugging devices. One thing I noticed is that if I have Pd running only a sine wave, then I plug or unplug a USB device, I get an interruption in the sound. If I do the same thing with Audacity or Max/MSP, there is not interruption in the sound. Any ideas what's the root of this? I have no idea about the inner workings of hidio (is there a separate low-priority thread for handling the HID requests?), but Max/MSP has a different thread for DSP processing, and messaging is split into high and low-priority tasks. best greetings, Thomas -- Thomas Grill http://g.org ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] devel branch
Hi Tim, you know that pnpd has a different license than pd, not allowing such usage, except you relicense this part of the code. The other thing is that i guess it has to be straight C for Miller to accept it, plus, older gcc versions have problems with intrinsics in c ++ code. all the best, Thomas Am 03.12.2006 um 23:06 schrieb Tim Blechmann: hi thomas, Once i started the new devel branch, i'll try to provide patches of the various extra features, which would save you from brwosing through the codebase. I'm wondering if we can find a way to even include SIMD, since i'm going to reimplement it without using assembly but rather compiler instrinsics i've implemented most of the vectorizable dsp functions with intrinsics for pnpd. it's written with c++ templates, but it should be easy to wrap these functions into a c api for pd. possibly faster to reuse this code than rewriting the codelets from scratch and they are quite separate from the pnpd codebase, just implemented as header files. cheers ... tim -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk The price an artist pays for doing what he wants is that he has to do it. William S. Burroughs Thomas Grill http://g.org ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] devel branch
Am 03.12.2006 um 23:35 schrieb Tim Blechmann: The other thing is that i guess it has to be straight C for Miller to accept it, yes, possibly ... plus, older gcc versions have problems with intrinsics in c ++ code. well, older gcc versions have problem with intrinsics in general. ;) older here means 4.0.1, which is the standard compiler in OSX 10.4. as for the license, it could be optional like the fftw support ... no option for a devel branch, that vibrez wants to use. all the best, Thomas -- Thomas Grill http://g.org ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] devel branch
Hi all, since things have been cleared up now, and obviously i have been assigned the role of the keeper of the devel, i'm thinking of how to proceed with the mentioned branch. A few points i'm considering: - I have no interest in maintaining a branch open for the public, when i'm the only user of it. It would be much more comfortable to keep it at home, with all the freedom to make changes where i like, not having to keep an eye on compatibility - I'd find it beneficial to integrate Miller's changes that happened since the last merge - It would be nice to be able to provide patches of the devel improvements for Miller, without investing a lot of time into it - I'd like to use the autobuild system - We need many of the extra features in devel for the vibrez project, hence we have to keep them The following solution comes to my mind: - Make a list of things that are special for devel_0_39 (also asking other devel contributors). - Branch off a devel branch (without version number) from Miller's latest cvs - Gradually integrate the listed devel features into the branch, and also making patches for Miller - Rethink some architectural details, like the SIMD infrastructure (ability to inline functions and enable auto-vectorization) I think this is less work than merging in Miller's version into devel and it also makes later incremental updates easier. Miller's version and the devel branch can progress side by side. Any ideas, comments, lamento? best greeting, Thomas -- Thomas Grill http://g.org ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] Re: PD-cvs Digest, Vol 21, Issue 30
Hi Mathieu,
i have been following the latst cvs changes and it seems, you are
again beautifying the codebase.
Please identify the parts that you consider that I'm just
beautifying, apart from the files that don't belong to your part of
devel_0_39.
Actually, you should know what you changed. Only from the latest cvs digest:
Message: 6
Date: Tue, 28 Nov 2006 15:36:07 +
From: Mathieu Bouchard [EMAIL PROTECTED]
Subject: [PD-cvs] pd/src x_list.c,1.2.2.7,1.2.2.8
To: [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
Update of /cvsroot/pure-data/pd/src
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv19418
Modified Files:
Tag: devel_0_39
x_list.c
Log Message:
removed useless reference to global var newest.
Index: x_list.c
===
RCS file: /cvsroot/pure-data/pd/src/x_list.c,v
retrieving revision 1.2.2.7
retrieving revision 1.2.2.8
diff -C2 -d -r1.2.2.7 -r1.2.2.8
*** x_list.c30 Nov 2005 13:36:58 -1.2.2.7
--- x_list.c28 Nov 2006 15:36:03 -1.2.2.8
***
*** 21,27
#endif
- extern t_pd *newest;
-
-
/* the list object family.
--- 21,24
***
*** 397,419
{
if (!argc || argv[0].a_type != A_SYMBOL)
! newest = list_append_new(s, argc, argv);
else
{
t_symbol *s2 = argv[0].a_w.w_symbol;
! if (s2 == gensym(append))
! newest = list_append_new(s, argc-1, argv+1);
! else if (s2 == gensym(prepend))
! newest = list_prepend_new(s, argc-1, argv+1);
! else if (s2 == gensym(split))
! newest = list_split_new(atom_getfloatarg(1, argc, argv));
! else if (s2 == gensym(trim))
! newest = list_trim_new();
! else
! {
! error(list %s: unknown function, s2-s_name);
! newest = 0;
! }
}
- return (newest);
}
--- 394,408
{
if (!argc || argv[0].a_type != A_SYMBOL)
! return list_append_new(s, argc, argv);
else
{
t_symbol *s2 = argv[0].a_w.w_symbol;
! if (s2 == gensym(append)) return list_append_new(s,
argc-1, argv+1);
! if (s2 == gensym(prepend)) return list_prepend_new(s,
argc-1, argv+1);
! if (s2 == gensym(split)) return
list_split_new(atom_getfloatarg(1, argc, argv));
! if (s2 == gensym(trim))return list_trim_new();
! error(list %s: unknown function, s2-s_name);
! return 0;
}
}
--
Message: 7
Date: Tue, 28 Nov 2006 15:46:11 +
From: Mathieu Bouchard [EMAIL PROTECTED]
Subject: [PD-cvs] pd/src x_connective.c,1.3.4.1.2.8,1.3.4.1.2.9
To: [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
Update of /cvsroot/pure-data/pd/src
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv23183
Modified Files:
Tag: devel_0_39
x_connective.c
Log Message:
removed useless access to newest.
Index: x_connective.c
===
RCS file: /cvsroot/pure-data/pd/src/x_connective.c,v
retrieving revision 1.3.4.1.2.8
retrieving revision 1.3.4.1.2.9
diff -C2 -d -r1.3.4.1.2.8 -r1.3.4.1.2.9
*** x_connective.c30 Nov 2005 13:36:58 -1.3.4.1.2.8
--- x_connective.c28 Nov 2006 15:46:09 -1.3.4.1.2.9
***
*** 9,13
#include string.h
#include stdio.h
- extern t_pd *newest;
/* -- int -- */
--- 9,12
***
*** 67,71
outlet_new(x-x_obj, s_float);
floatinlet_new(x-x_obj, x-x_f);
- newest = x-x_obj.ob_pd;
return (x);
}
--- 66,69
***
*** 110,114
outlet_new(x-x_obj, s_symbol);
symbolinlet_new(x-x_obj, x-x_s);
- newest = x-x_obj.ob_pd;
return (x);
}
--- 108,111
***
*** 166,170
t_bang *x = (t_bang *)pd_new(bang_class);
outlet_new(x-x_obj, s_bang);
- newest = x-x_obj.ob_pd;
return (x);
}
--- 163,166
--
Thomas Grill
http://g.org
___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
[PD-dev] Re: PD-cvs Digest, Vol 21, Issue 30
While i don't see what that feature might be in these code excerpts, except the elimination of an unneeded variable and reformatting, i normally don't spend my time proof-reading devel_0_39. Anyway, i hope you know what i mean. Merging in 0.40 could be beneficial for all of us, and i it can be tackled the sooner, the less work it is. greetings, Thomas Am 29.11.2006 um 16:28 schrieb Mathieu Bouchard: On Wed, 29 Nov 2006, Thomas Grill wrote: i have been following the latst cvs changes and it seems, you are again beautifying the codebase. Please identify the parts that you consider that I'm just beautifying, apart from the files that don't belong to your part of devel_0_39. Actually, you should know what you changed. Only from the latest cvs digest: Actually, I still wanted you to identify it because I wanted to make sure that we agree on what it might be, and because the code you point out is part of the implementation of a feature. While you were writing the above mail, I was writing a mail about that feature, because that's something I _broke_ in devel_0_39 yesterday. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Re: PD-cvs Digest, Vol 21, Issue 30
First, i would be extremely cautious about making strange assumptions about other people's problems. Second, i think the whole case will solve itself shortly, because after the merge a devel branch will probably not be called devel_0_39 any more. It may also be a move back to more compatibility to Miller's branch, or not. all the best, Thomas Mathieu Bouchard schrieb: On Wed, 29 Nov 2006, Georg Holzmann wrote: No, but you said it yourself: you joined (after impure data) the pd_devel branch so that you can also benefit from those improvements ... Yes, but that was conditional to having such improvements. I think that I was somewhat mistaken when I first joined devel_0_39, I thought that it was going to be somewhat more dynamic than that. Turns out that: 1. I had the delusion that there were more developers working on devel_0_39, but I hadn't counted. Turned out that it wasn't true. 2. Tim is basically on the way out: keeps using pd for backwards-compatibility reasons. 3. Thomas has a hidden branch because devel_0_39 is too dangerous because I could be committing files in it. 4. At this point (these months...), the only other regular contributors to devel_0_39 are Chun Lee and myself. Now there is already the main and devel/desire_data branch and I think such a marginal problem as you have (the beautification ...) should not be the reason for one more branch ... Well, you shouldn't confuse the actual with problem, with something that is just a trigger (a catalyser) for change. Thomas's problem is just an occasion for taking the time for a reality check about the issue, and summarise all the issues that have accumulated during the 16 months of having devel_0_39 and desiredata two-in-one. I don't see the branching as being a big change, nor as a surprise, nor as being weird or out-of-place or bad manners. That said, I don't want to switch to another repository as of now; I don't see its advantages as being greater than its inconvenients. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada -- Thomas Grill http://g.org ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] pool files: UTF-8 encoding
Hi all, trying to fix loading/saving of non-ASCII characters in pool files. In the future, text files will still be saved in the native encoding, but XML will be UTF-8. Since i'm not very linux-savvy: I guess the default code table used for PD patchers is the same as being used for the X-server, right? Is there an API function to query this encoding and/or is there a system function to convert from/to UTF-8? best greetings, Thomas -- Thomas Grill http://g.org ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Fwd: PD-cvs Digest, Vol 21, Issue 29
Hans-Christoph Steiner schrieb: I reduced the autobuild report from 200 to 20 lines. That should help. I was hoping to have the autobuild reports not in the digest so that they are more apparent. That sounds like a good solution. I have to say that I am very surprised that the autobuilds aren't being used by vibrez/devel, especially when working towards a release. It makes that job much, much easier. vibrez is a project that aims at good stability, hence it's too dangerous to compile directly from the cvs. Concerning pd-devel, it might be worth looking into it, although it's more urgent to merge in the changes from 0.40 best greetings, Thomas -- Thomas Grill http://g.org ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] gcc 4.1 and auto-vectorization
Am 19.11.2006 um 05:00 schrieb Hans-Christoph Steiner: On Nov 18, 2006, at 8:07 PM, Thomas Grill wrote: Am 18.11.2006 um 22:16 schrieb Mathieu Bouchard: On Sat, 18 Nov 2006, Hans-Christoph Steiner wrote: I really doubt that the gcc devs put a lot of effort into something that has no effect. Perhaps not for Pd, that may be true. But they are talking about vectorizing loops, it may not be the best thing to vectorize, but there are definitely vectorizable loops in Pd. perhaps it would be a good start to reimplement newbytes(n) using memalign(16,n) instead of malloc(n). A few years ago i introduced aligned memory allocation in the pd- devel branch. Have you tried submitting a patch? It would be at least useful in Pd-extended. How big a difference did it make? I have a better idea. People interested in improvements can easily make a diff from the devel branch. The aligned memory allocation is part of the SIMD codelets which have been part of pd-devel for a long time. best greetings, Thomas ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] gcc 4.1 and auto-vectorization
Hi H.C., It generally accepted procedure in the projects that I've seen that people guide their own code thru the procedures of submitting patches and getting them accepted. I think that makes sense here too. Its coming quite clear that devel/dd is fork since the devel/dd devs are resistant or unwilling to try to get code into pd-MAIN. well, you perfectly know that this isn't true. I have been submitting many patches and bug reports over the last years, but i don't see why i should invest my really scarce time in something that's senseless. If i would have submitted the patch for SIMD two or three years ago (by the time i made the relevant changes), it would have been automatically discarded in the meantime, simply because Miller has shown zero interest in using it. The SIMD patch would have been a lot of work - wasted time, that i could have used for other developments or even for composing music. That's too bad, I think we will all be the worse for it, but its your choice to do so. I think it would be helpful to make it clear that its a fork instead of continuing to skirt the issue. I'll be continuing submitting patches that aren't a lot of work, like bug fixes. For other stuff (like the existing audio and midi fixes, idle callbacks, SIMD, or other features i have in mind) interested people are more than welcome to keep track of the changes and submit them. I don't see why necessarily i should do it. If it helps i'll also announce to the pd-devel list when new features are introduced. best greetings, Thomas ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] gcc 4.1 and auto-vectorization
Am 19.11.2006 um 22:57 schrieb Mathieu Bouchard: On Sun, 19 Nov 2006, Thomas Grill wrote: Am 18.11.2006 um 22:16 schrieb Mathieu Bouchard: perhaps it would be a good start to reimplement newbytes(n) using memalign(16,n) instead of malloc(n). A few years ago i introduced aligned memory allocation in the pd- devel branch. I see how you did it. Is it because posix_memalign() isn't as portable as we'd like it to be? (I wrote memalign by mistake, which is the name of a deprecated function that does a similar job) It seems like a lot of memory is allocated unaligned. Is that normal? If the memory allocations you've align cover the most speed- critical memory, then why did Tim say that about memory alignment? The point is that i only introduced and used the aligned memory functions for the SIMD codelets, which are used for DSP and array processing. I'm sure that there are aligned memory allocation functions for either platform (maybe not necessarily posix_memalign...), but i wanted to stay as close as possible to the original PD memory functions. I don't think it makes much sense to use aligned memory for anything else than DSP and tables. If one wanted to use it with auto- vectorization the header code would be much the same as the one in the DSP perform functions, with some casting to aligned pointers, so that the compiler knows about it. Aliasing is another thing, though. greetings, Thomas ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] BUG: namespace prefixes broken in 0.40
Hi all, (Optional) keyword arguments are a long-term wishlist item, because only having positional arguments is not very comfortable. It would be great to have a corresponding object or syntax to read out keyword arguments in abstractions. I think, Thomas Grill write somthing like that for the flext-syntax. it's in the cvs in externals/grill/absattr From a qwertz-keyboard user's view I would prefer the -key syntax over flext's @key syntax. i only chose that because it's already known in the patcher world, due to Max/Jitter. I didn't want to introduce another standard, when there's no real reason to do that. greetings, Thomas -- Thomas Grill http://g.org ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] pure data patch MIME type
Hi all, has someone already made an attempt to register a MIME type for pd patches? Looking in the IANA registry (http://www.iana.org/assignments/media-types ) it seems to be feasible to call it text/vnd.puredata.patch or something like that (this doesn't require an RFC). Any opinions? best greetings, Thomas -- Thomas Grill http://g.org ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] how does a loader get loaded?
Am 25.09.2006 um 00:32 schrieb Hans-Christoph Steiner: Weee a tongue twister! So I am working on making a loader for libdirs. I get sys_register_loader(), which submits a pointer to classloader() (or whatever). But what makes Pd load that loader first? For example, something needs to load clr.dll, so that is calls sys_register_loader() to register its classloader() function. yes, it's the good old -lib clr command line option! greetings, Thomas ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] passing command line args to pd on OSX
Hi all, the packaging of PD no OSX as a modified wish standalone application has the disadvantage that it's obviously not possible to pass on command-line args, such as /Applications/Pd-0.39-2.app/Contents/MacOS/Pd -verbose because -verbose would be an option for wish than, or /Applications/Pd-0.39-2.app/Contents/MacOS/Pd -- -verbose because passing on args from the pd.tk script is not implemented. I would do that but unfortunately i'm not able to suppress my disgust against tcl/tk, although that would be a very useful enhancement. I guess it's fairly easy to do - someone who wants to have a look? greetings, Thomas -- Thomas Grill http://g.org ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] VASP vs plugin~ weirdness
Hi Michal, it would be useful to have more detailed information about your configuration. Platform? PD version? VASP version, downloaded as a package or from CVS? greetings, Thomas Am 10.08.2006 um 07:16 schrieb Michal Seta: Hi all, there is some weirdness happening when VASP is being loaded as -lib (ok, perhaps I shouldn't do such things) and [plugin~] is being used. The combination results in a segfault. I had exactly the same issue with [pool] a while back (and it was in fact pointed out to me that I should report this to the list but it slipped my brain). ./MiS ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev Thomas Grill http://g.org ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
