Pd-dev May 2014

pd-dev@lists.iem.at

17 participants
11 discussions

pd-extended installer puts libraries in system32 folder. Is it a bad idea?
by Rafael Vega 25 Sep '14

25 Sep '14

Hi. First post here :) I just spent a couple of hours figuring out why a c++ program I compiled on windows (not my main OS) would not run. I am linking my program with libstdc++ and compiling with the MinGW toolset. Now, I have pd-extended installed on the same machine and when it installed, it put it's own copy of libstdc++ in c:\WINDOWS\system32. The way Windows loads libraries is: first looks on the directory where the exe is, then it looks on the system folder and then it looks on the PATH. The problem with my program was, then, that the MinGW linker did not like the version of libstdc++ put in the system folder by pd-extended installer. Uninstalling pd-extended "fixed" the issue. So, I just want to throw this out there: Should the pd-extended installers avoid putting libraries on the system folder to avoid this kind of confusion? My 2 cents. Thanks! :) -- Rafael Vega email.rafa(a)gmail.com

2 1

Re: [PD-dev] libpd partly working with pd instances
by Dan Wilcox 28 May '14

28 May '14

Sure. I guess I don't know what I'm saying :D other than the question: what do we reasonably need? Does the current solution work or is the next step required? On May 22, 2014, at 5:03 PM, pd-dev-request(a)lists.iem.at wrote: > To me, I think the ultimate use case is to be able to fire up two versions of pd in the same processing chain (take vst's in a DAW for example), load each one with identical patches, and have them controlled separately. This would be a fantastic boost for the ability to extend what we can already do with Pd as an audio processing engine, separated from its native GUI. Locking may be necessary in places, but then that is extremely fast these days. > > Of course, this all leads to the pdinstance being able to manage the symbol table along with Miller's recent changes, but what are the difficulties in achieving this? It seems like Miller tried and it was more difficult than what we are imagining. > > cheers, > Rich -------- Dan Wilcox @danomatika danomatika.com robotcowboy.com

5 4

beatcoins for sale
by Jonathan Wilkes 22 May '14

22 May '14

0 = silence 1 = bass 2 = snare Here are some freebies in 12/8: 1 0 0 2 0 1 1 0 1 2 0 0 [seed 229380( | [random 3] 1 0 0 2 0 1 1 0 0 2 1 0 [seed 864982( | [random 3] 1 0 0 2 1 1 1 0 1 2 1 1: [seed 348501( | [random 3] That's 3 floats and a [random] for 1 beat plus 2 fills! The savings are incredible!!! Bonus: MELODYCOINS. Here's the Intel melody on a diatonic scale: [seed 1089( | [random 5( Forget all that boring iteration through lists-- seed your randomness with BEATCOINS and your beats will always be tight and tasty! -Jonathan

1 0

Re: [PD-dev] libpd partly working with pd instances
by Dan Wilcox 22 May '14

22 May '14

Howdy Miller, This looks great and is definitely something we've been excited about. On May 11, 2014, at 6:00 AM, pd-dev-request(a)iem.at wrote: > To Pd developers... > > I've adapted Pd to nternally use a "pdinstance" structure to allow > multiple schedulers (including DSP chains) to run in one address space. > With slight modification (see below) libpd can use this to run separate > patches asynchronously. > > I tried to "instance-ize" all Pd symbols to keep them private but ran into > seemingly insoluble problems, so am leaving all symbols global for now. > (So patches used in pdlib, if they want to be usable in a multiple-instance > scenaro, should protect all send/receive/table/delay/etc named objects with > a $[0-9] somewhere. Judging from quickly scanning the test code, the main difference on our end would be switching context between instances? I was brainstorming a future api for multiple instances along the lines of simply adding a instance index or pointer version of each of the existing libpd api calls, such as: int libpd_bang(const char *destination); // current function int libpd_bang(t_pdinstance* instance, const char *destination); // additional instance version (probably better to use a pointer, etc) We could then call pd_setinstance, pdinstance_new etc internally ... t_pdinstance* libpd_init(); // default, single use case; sets internal default instance pointer and returns it int libpd_init(t_pdinstance* instance); // creates a new instance, returns 0 on success ... but in the end perhaps simply adding the new functions directly is simpler: t_pdinstance* libpd_init(); // returns default internal instance or null on failure t_pdinstance* libpd_new_instance(); void libpd_set_instance(t_pdinstance* instance); > I didn't look hard, but I thnk pdlib now will need a way to send $ arguments > to patches via libpd_openfile() somehow. Also, libpd_init_audio() will want to > make number of channels per-instance, etc. I've put some relevant comments > in the test program I'll include below (and sorry for the length of this > mail!) Ok cool. We've got something to go on, great! -------- Dan Wilcox @danomatika danomatika.com robotcowboy.com

6 7

Re: [PD-dev] Pd-dev Digest, Vol 110, Issue 16
by Dan Wilcox 22 May '14

22 May '14

On May 22, 2014, at 6:00 AM, pd-dev-request(a)lists.iem.at wrote: > But for now, if you want to make a Pd wrapper VST plugin, you can just put locks around all > pd calls. I think this first step is a good one. I'm not convinced it's necessary to > do the next step, but let's see how this works first. At least it's nice to be able to send > and receive pd messages between instances easily. The issue is, I think, that it feels like we might have the chance to get real multi-context, separate symbols. It would be really great to discuss this and maybe see it happen as opposed to 5 years from now. If it simply involves just lots of symbol renaming, count me first on the list of volunteers. I'll do the dirty work if required. It feels like the current work is definitely *almost* there and I'm really happy. I'd just like to know what's required to take it that extra step and let's see if we can do it *now*. > If you really want to run things in parallel, you can always just run Pd in a new process, which is much safer too. Cool but how do I run "just run Pd in a new process" on iOS? I brought up this further separation question to see if the currently solution works for most of the use cases we'd see with libpd. It sounds like you answered that with a "no": "If you really want to run things in parallel...". Remember, at this point, I believe libpd is being mostly used for iOS apps, with desktop being second (you can just run pd+gui there). I think we need other libpd iOS developers etc to chime in on whether the current solution is all that's needed or whether the next step is required. I'm all for choosing what's good now over what's best, but I'm not sure if this case is good enough, so I wanted to ask everyone. I'm not sure if we've gotten an answer yet ... -------- Dan Wilcox @danomatika danomatika.com robotcowboy.com

1 0

[pure-data:bugs] #1144 Template makefile not compiling on osx 10.9.3 / -ftree-vectorizer-verbose=2 error
by Nicolas Montgermont 21 May '14

21 May '14

--- ** [bugs:#1144] Template makefile not compiling on osx 10.9.3 / -ftree-vectorizer-verbose=2 error** **Status:** open **Group:** v0.45 **Created:** Wed May 21, 2014 10:18 AM UTC by Nicolas Montgermont **Last Updated:** Wed May 21, 2014 10:18 AM UTC **Owner:** nobody Hello, svn pmpd was not compiling on osx mavericks 10.9.3, it raises the error: clang: error: unknown argument: '-ftree-vectorizer-verbose=2' [-Wunused-command-line-argument-hard-error-in-future] To make it compile, one just have to remove the parameter -ftree-vectorizer-verbose=2 on the line 106 of the makefile: OPT_CFLAGS = -ftree-vectorize -fast It uses the template makefile v 1.0.14 (last svn version) so the generic makefile should be updated as well. --- Sent from sourceforge.net because pd-dev(a)lists.iem.at is subscribed to https://sourceforge.net/p/pure-data/bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pure-data/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

1 0

libpd partly working with pd instances
by Miller Puckette 15 May '14

15 May '14

To Pd developers... I've adapted Pd to nternally use a "pdinstance" structure to allow multiple schedulers (including DSP chains) to run in one address space. With slight modification (see below) libpd can use this to run separate patches asynchronously. I tried to "instance-ize" all Pd symbols to keep them private but ran into seemingly insoluble problems, so am leaving all symbols global for now. (So patches used in pdlib, if they want to be usable in a multiple-instance scenaro, should protect all send/receive/table/delay/etc named objects with a $[0-9] somewhere. I didn't look hard, but I thnk pdlib now will need a way to send $ arguments to patches via libpd_openfile() somehow. Also, libpd_init_audio() will want to make number of channels per-instance, etc. I've put some relevant comments in the test program I'll include below (and sorry for the length of this mail!) Here's how I modified libpd_wrapper/z_libpd.c: 55d54 < sys_time = 0; 110c109 < sched_tick(sys_time + sys_time_per_dsp_tick); --- > sched_tick(); 130c129 < sched_tick(sys_time + sys_time_per_dsp_tick); \ --- > sched_tick(); \ ---------------------- and here (sorry again) is the test program, "pdtest2.c" adapted from libpd-master/samples/c_samples/c/pdtest.c : --------------------- #include <stdio.h> #include "z_libpd.h" #include "m_imp.h" #define TIMEUNITPERMSEC (32. * 441.) void pdprint(const char *s) { printf("%s", s); } void pdnoteon(int ch, int pitch, int vel) { printf("noteon: %d %d %d\n", ch, pitch, vel); } int main(int argc, char **argv) { t_pdinstance *pd1 = pdinstance_new(), *pd2 = pdinstance_new(); if (argc < 3) { fprintf(stderr, "usage: %s file folder\n", argv[0]); return -1; } int srate = 44100; // maybe these two calls should be available per-instnace somehow: libpd_set_printhook(pdprint); libpd_set_noteonhook(pdnoteon); /* set a "current" instance before libpd_init() or else Pd will make an unnecessary third "default" instance. */ pd_setinstance(pd1); libpd_init(); /* ... here we'd sure like to be able to have number of channels be per-nstance. The sample rate is still global within Pd but we might also consider relaxing that restrction. */ libpd_init_audio(1, 2, srate); float inbuf[64], outbuf[128]; // one input channel, two output channels // block size 64, one tick per buffer pd_setinstance(pd1); // talk to first pd instance // compute audio [; pd dsp 1( libpd_start_message(1); // one entry in list libpd_add_float(1.0f); libpd_finish_message("pd", "dsp"); // open patch [; pd open file folder( libpd_openfile(argv[1], argv[2]); pd_setinstance(pd2); // compute audio [; pd dsp 1( libpd_start_message(1); // one entry in list libpd_add_float(1.0f); libpd_finish_message("pd", "dsp"); // open patch [; pd open file folder( libpd_openfile(argv[1], argv[2]); /* the follownig two messages can be sent without setting the pd nstance and anyhow the symbols are global so they may affect multiple instances. However, if the messages change anyhing in the pd instacne structure (DSP state; current time; list of all canvases n our instance) those changes will apply to the current Pd nstance, so the earlier messages, for instance, were sensitive to which was the current one. Note also that I'm using the fact taht $0 is set to 1003, 1004, ... as patches are opened -it would be better to opent the patches with settable $1, etc parameters to libpd_openfile(). */ // [; pd frequency 1 ( libpd_start_message(1); // one entry in list libpd_add_float(1.0f); libpd_finish_message("1003-frequency", "float"); // [; pd frequency 1 ( libpd_start_message(1); // one entry in list libpd_add_float(2.0f); libpd_finish_message("1004-frequency", "float"); // now run pd for ten seconds (logical time) int i, j; for (i = 0; i < 3; i++) { // fill inbuf here pd_setinstance(pd1); libpd_process_float(1, inbuf, outbuf); if (i < 2) { for (j = 0; j < 8; j++) printf("%f ", outbuf[j]); printf("\n"); } pd_setinstance(pd2); libpd_process_float(1, inbuf, outbuf); if (i < 2) { for (j = 0; j < 8; j++) printf("%f ", outbuf[j]); printf("\n"); } } return 0; } ---------------------- I replaced "test.c" as follows: --------------------- #N canvas 406 290 450 300 10; #X obj 97 64 loadbang; #X obj 97 131 print; #X obj 186 106 dac~; #X obj 97 107 f 0; #X obj 128 107 + 1; #X obj 97 86 metro 2; #X obj 185 41 r \$0-frequency; #X obj 188 73 osc~; #X obj 248 127 print \$0-frequency; #X obj 248 97 loadbang; #X connect 0 0 5 0; #X connect 3 0 1 0; #X connect 3 0 4 0; #X connect 4 0 3 1; #X connect 5 0 3 0; #X connect 6 0 7 0; #X connect 6 0 8 0; #X connect 7 0 2 0; #X connect 7 0 2 1; #X connect 9 0 8 0; ---------------------------- and got this output: print: 0 1003-frequency: bang print: 0 1004-frequency: bang 1003-frequency: 1 1004-frequency: 2 1.000000 1.000000 0.999999 0.999999 0.999998 0.999998 0.999997 0.999997 1.000000 1.000000 0.999998 0.999998 0.999996 0.999996 0.999995 0.999995 print: 1 0.999944 0.999944 0.999943 0.999943 0.999942 0.999942 0.999941 0.999941 print: 1 0.999815 0.999815 0.999810 0.999810 0.999804 0.999804 0.999799 0.999799 print: 2 print: 2 ... Looks like there are 2 schedulers adn DSP chains running :) Miller

5 8

Strange error with binbuf and symbol on Linux
by Pierre Guillot 14 May '14

14 May '14

Hi everybody, I have a strange bug only on Linux. When I create a t_symbol with @ inside it and try to add it to a binbuf PD crashes . dummy code that crashes: t_gotfn mpreset = zgetfn(&y->g_pd, s_preset); SETSYMBOL(av, gensym("@zaza")); binbuf_add(b, 1, av); mpreset(y, b); (it seems to crash here) dummy code that works: t_gotfn mpreset = zgetfn(&y->g_pd, s_preset); SETSYMBOL(av, gensym("zaza")); binbuf_add(b, 1, av); mpreset(y, b); I don't know if it's a linking problem or if I do something wrong in the code. Any help will be welcome ! Here the link of the full project : https://github.com/CICM/CicmWrapper In the CreamLibrary folder, you can use the codeblock project "c.library" if you want to try it. And the bug is in the function "preset_store" of the file "c.preset.cpp" in the chocolate subfolder. Cheers

2 2

puredata.info new hardware
by IEM - network operating center (IOhannes m zmoelnig) 14 May '14

14 May '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 hi, as announced on pd-announce/pd-list, we have migrated puredata.info to a new host. while doing so, we upgraded all software to newer versions, including openssl (the old one was so old, that it didn't even expose the heartbleed bug) and openssh. this is important for all those running auto-builds and who do uplaods to autobuild.puredata.info/apt.puredata.info via ssh/rsync, as the SSH host keys have been re-created (and thus changed). this is the new RSA key fingerprint for puredata.info: 54:81:b1:cc:0f:40:a4:ac:fc:9f:c0:28:a0:7a:f3:3f yours never-tiring, fgasdmr IOhannes - -- IEM - network operation center mailto:noc@iem.at -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJTc3bEAAoJELZQGcR/ejb49Z8QAJGK3/vYxQHYmeqpFBl9lKuw YXQKJZP/JzyANVEk43O8vdvzDWWguNLnzM/INwyb73yU+0lPib+DQVONoDFQ4j0v KkPg/ghKue+TY/Yim2qGxu4BE4dCRMVzF/0msfk6e7eQG2ZVsKaCg3SDReMsECqZ qFY4q4rdhfF1UHlouIwRlJy4uBR2ElCqrwxajSzZiBWzkwOmoEja+UW9AouXmXdo AhFm3UrVZAkAZDdw3WFwWMcB1Aw/IoP01DA2cC9Mik+TSXOSmlnuhCpakN/Y1Ynv yVRqblIfV3rRavotNWNLV0bgGJLTIniHgOpWZ/sMU5covkjBIHaDxAukTzI5l1qM 5KFfd0V8AcWwlgzp0IgGexCWDmSmEmjAzul4CxR6FTAE9tkKNW11RFo5kkLXiYny PYtlEaTYqfpNGvOEh+sNxymcxQ6XmWZ17vE+xZL6te8YytLmSleZGsTZnkPwFqbZ oApqpJ/6ZneZ7KnidVl6aJMvEj21opbBP3sYYUIA0bVAnghvUCL4w2K2y+3MMeJ1 J5PqQ9bxRkzH2uEBQDQhc/m0KruKh0wKUFMquntHN+ui6MT/6NSMTbQMfVk7RuSA YmIxK5AlbQ6KycMFQ2d2zV7IX7+jb44u291Q3fuvyGABoTrLP9Nh61dpnvJhnjsM 5i+NMxsQ5jwEqBCsZHa0 =XabR -----END PGP SIGNATURE-----

1 0

[pure-data:feature-requests] #137 Create sub patches from selected objects
by hellocatfood 06 May '14

06 May '14

--- ** [feature-requests:#137] Create sub patches from selected objects** **Status:** open **Group:** Next Release (example) **Created:** Mon May 05, 2014 10:11 PM UTC by hellocatfood **Last Updated:** Mon May 05, 2014 10:11 PM UTC **Owner:** nobody Can a method be added to make selected objects into a sub patch that automatically adds [inlets] and [outlets] and retains all cord connections? --- Sent from sourceforge.net because pd-dev(a)lists.iem.at is subscribed to https://sourceforge.net/p/pure-data/feature-requests/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pure-data/admin/feature-requests/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pd-dev May 2014