Re: [PD] Pd FLOSS manual update

> I recently had a look at the Pd FLOSS manual (Pd FLOSS) and seems a bit out > of date. so I was wondering if there's anyone interested in updating and > expanding it. I have at times thought about doing this, especially the stuff about GEM and visuals > so which Pd version should be used for

[PD] [PD-announce] NIME 2018 workshop and demo deadline March 1st

NIME 2018 Call for submissions Please pardon the cross-posting, *A friendly reminder that the submission deadline of March 1st, 2018, for the NIME 2018 conference workshops and non-paper demos is now less than 24 hours away. Additional information is available on the website (**NIME2018.ORG

Re: [PD] Text projection in real time

Hello João, Le 28/02/2018 à 19:31, João Pais a écrit : > Hello list, > > I was looking on the best way to display some texts which will be > produced/improvised in realtime. These will be acessible either as a > list, OSC, or on a file. > > I tried gem's 2dtext and [flatgui/entry], but they

Re: [PD] Speech recognition on Pure Data

Again, not within Pd, but we had some success using the CMU Sphinx 4 Java library and Processing for this project: http://danomatika.com/projects/trust-me I'm not sure if a Java app will be too heavy for an embedded board though, but I can send along

Re: [PD] Text projection in real time

Have you tried ofelia ? it's pretty new but there are some objects available for text display and it should be pretty straigthforward with [ofDrawText] and [ofSetTextMode] https://github.com/cuinjune/ofxOfelia It should pretty do-able with processing aswell. 2018-02-28 20:17 GMT+01:00 Christof

Re: [PD] Text projection in real time

for text display the browser is a naturally choice. I once did some experiments sending and receiving Pd messages with a minimal websockets implementation and it worked fine. > Gesendet: Mittwoch, 28. Februar 2018 um 19:31 Uhr > Von: "João Pais" > An: PD-List

[PD] Text projection in real time

Hello list, I was looking on the best way to display some texts which will be produced/improvised in realtime. These will be acessible either as a list, OSC, or on a file. I tried gem's 2dtext and [flatgui/entry], but they both don't work that well, as some or all of the following aren't

Re: [PD] Speech recognition on Pure Data

Hi, On 28/02/18 16:53, Ariane stolfi wrote: > I'm planning to work on a project that will use a microphone to query on > freesound database, and we are planning to use speech recognition to > send the queries.  We will use pure data installed in a Bella board and > e-textile sensors to process

[PD] Speech recognition on Pure Data

Hi, I'm planning to work on a project that will use a microphone to query on freesound database, and we are planning to use speech recognition to send the queries. We will use pure data installed in a Bella board and e-textile sensors to process the sound. I'm considering send audio and do the

[PD] Fw: Re: stale pointers after object creation (was Re: pix_data issue)

OK, I see that the refcount is not per scalar but per glist (in t_gstub) so if I understand correctly it's not possible to selectively invalidate gpointers only for the deleted scalars. also I have to correct myself: adding scalars doesn't invalidate pointers. so the remaining problem is

Re: [PD] stale pointers after object creation (was Re: pix_data issue)

> a glist (list of graphical objects) is internally implemented as a linked > list. usually, a big > advantage of a linked lists is that adding/deleting elements won't touch > other elements > (especially doesn't move them in memory, like it can happen with dynamically > sized arrays).

Re: [PD] stale pointers after object creation (was Re: pix_data issue)

I noticed this issue ca. one year ago when I started working on a complex project with data structures which involved dynamically adding/deleting objects to/from a canvas. I even submitted a bug report: https://sourceforge.net/p/pure-data/bugs/1282/ since I've recently started doing a couple a

Re: [PD] Pd-0.48: native english interface

On 02/28/2018 12:10 PM, Thomas Grill wrote: > Thanks Dan! > My dumb question has been sufficiently answered for me and the archive. btw, your question triggered a slight change in the Debian packages: you can now (un)install the translation files separately (they have moved into their own

Re: [PD] Pd-0.48: native english interface

Out of curiosity, which method did you end up using? We could add it to the readme or at least make that info a more obvious section. > On Feb 28, 2018, at 12:10 PM, Thomas Grill wrote: > > Thanks Dan! > My dumb question has been sufficiently answered for me and the archive. >

[PD] stale pointers after object creation (was Re: pix_data issue)

Ok, so it is a combination of editing the canvas and pointer memory i don’t think it has to do with saving. also, i don’t think it would relate to the previous pix_data pointer issue Here’s a patch stale-pointer.pd Description: Binary data On Feb 28, 2018, at 11:24 AM, IOhannes m zmölnig

Re: [PD] Pd-0.48: native english interface

Thanks Dan! My dumb question has been sufficiently answered for me and the archive. best, Thomas > Am 26.02.2018 um 15:31 schrieb Dan Wilcox : > > A fourth option is to have the GUI simply *not* load locale info. Comment out > "load_locale" in pd-gui.tcl's main proc. > >>

[PD] readsf re-blocked up-sampled

Dear list, I am trying to put a [readsf~] inside a sub re-blocked and up-sampled following a previous conversation[1], using [block~]. Anyway, I don't get the correct up-sampling factor. Assuming the patch at sr = 44100 hz, the same for the audio file, blocksize 64 samples, I tried various

Re: [PD] pix_data issue

On 02/28/2018 10:53 AM, Fede Camara Halac wrote: > Would saving (cmd+s) make pix_data forget a pointer, as in [text] or [array] > objects when using pointers? that sounds very fishy to. do you have a patch that exposes the forget-on-save behaviour of [array] or [text]? gfmdasr IOhannes

Re: [PD] pix_data issue

Would saving (cmd+s) make pix_data forget a pointer, as in [text] or [array] objects when using pointers? (also, perhaps the [pointer] object itself, but I havent tested this) > On Feb 28, 2018, at 9:54 AM, IOhannes m zmölnig wrote: > > [pix_data] remembers that pointer

Re: [PD] pix_data issue

On 02/28/2018 10:45 AM, Jack wrote: > just a little remark : This is [pix_snap] (and not [pix_snapshot]) to doh. signature.asc Description: OpenPGP digital signature ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->

Re: [PD] pix_data issue

just a little remark : This is [pix_snap] (and not [pix_snapshot]) to get back pixels buffer from your gfx card to the RAM of your computer ;) ++ Jack Le 28/02/2018 à 09:54, IOhannes m zmölnig a écrit : > On 02/27/2018 11:50 PM, Derek Holzer wrote: >> >> I can disconnect the Gemlist from the

[PD] please don't use the l_ia64 extension (was Re: [PD-announce] ofelia v1.0.4: Pd external library written with openFrameworks)

On 02/28/2018 01:27 AM, Ed Kelly via Pd-list wrote: > Hmmm.I'm getting this extension on all the externals I compile on this > machine.1) When I compiled ofelia as an addon in the openFrameworks file > structure2) When I compile my own externals using a modified version of Hans' > Makefile > I

Re: [PD] [PD-announce] ofelia v1.0.4: Pd external library written with openFrameworks

On 02/28/2018 06:20 AM, Zack Lee wrote: > Hi IOhannes, > > Thank you for your suggestion. > I will recompile the external to use .pd_linux then. btw, you don't need to recompile. a simple rename (of the binary) would suffice. gfmadsr IOhannes signature.asc Description: OpenPGP digital

Re: [PD] pix_data issue

On 02/27/2018 11:50 PM, Derek Holzer wrote: > > I can disconnect the Gemlist from the second inlet, so that it is only > getting the metro bangs at the first inlet and the X and Y coordinates > to analyze at the third and fourth inlet, and still it gives data output. > > I know that it is still