Pd-dev June 2018

pd-dev@lists.iem.at

12 participants
14 discussions

Fwd: external help, please
by Alexandre Torres Porres 22 Aug '19

22 Aug '19

Hi folks, I need help on an external. I wanna perform a task on an array of signal inputs. It's a multichannel object, and I define the number of channels with an argument. Here's just the core of it, as an object named "mtx~", where I map the input to the output. And this is what happens. [image: Imagem inline 1] So you see I get a weird mirrored output, instead of something like "1 2 3 4 5 6". The perform method in the code is just static t_int *mtx_perform(t_int *w){ t_mtx *x = (t_mtx *)(w[1]); int nblock = (int)(w[2]); t_float **in_vectors = x->x_in_vectors; t_float **out_vectors = x->x_out_vectors; t_int i; for(i = 0; i < x->x_ch; i++){ t_float *in = in_vectors[i]; t_float *out = out_vectors[i]; t_int n = nblock; while(n--) *out++ = *in++; } return (w + 3); } What am I doing wrong? How should this go? See attached the help test example and code. Thanks

11 26

About inlet DSP prolog.
by Nicolas Danet 05 Aug '18

05 Aug '18

Hi, < https://github.com/pure-data/pure-data/blob/master/src/g_io.c#L210 > x->x_fill = x->x_endbuf - (x->x_hop - prologphase * re_parentvecsize); < g.io.c / line 210 > IMHO it does not properly shift the buffer in case of overlap (i.g. [block~ 512 4]) if stopping/restarting the DSP. x->x_fill = prologphase ? x->x_endbuf - (x->x_hop - prologphase * re_parentvecsize) : x->x_endbuf; The change above might solve the problem. I'm not 100 % sure. I'm currently testing the fix on Spaghettis < https://github.com/Spaghettis/Spaghettis/compare/dev >.

2 2

PD_LONGINTTYPE
by Christof Ressi 25 Jun '18

25 Jun '18

currently, we have to manually set PD_LONGINTTYPE to "long long" when compiling 64bit Pd for Windows (because on Windows "long" is always 32 bit, even in 64 bit programs). now my question: should we fix this in the makefile or directly in m_pd.h?

5 12

Compiling an external with stdc++ on Linux
by Pierre Guillot 20 Jun '18

20 Jun '18

Hi, I'm currently working on an external with the *FAUST* just-in-time (JIT) compiler embedded that allows to load, compile and play FAUST. I managed to compile a 64 bits version for Mac, Windows (yeah!) and Linux but on Linux I got a problem: The external has unresolved symbols: *__cxa_pure_virtual*. Here is the result of ldd: ldd ../external/faust~.pd_linux linux-vdso.so.1 => (0x00007ffcbf6d9000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fdeb864a000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fdeb8341000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fdeb8124000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fdeb7f0e000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fdeb7b44000) /lib64/ld-linux-x86-64.so.2 (0x00007fdebae31000) And when I link the external with *stdc++* to solve this problem, Pd crashes directly when I call *class_new()* - it's my 1st attempt with gdb so I didn't go very far. I only found that Pd crashes when the "setup" function is called. If I only use a "dummy" class_new() method - *t_class* c = class_new(gensym("faust~"), (t_newmethod)NULL, (t_method)NULL, s**izeof(t_faust_tilde), CLASS_DEFAULT, A_GIMME, 0);* - it also crashes. Here is the result of ldd: ldd ../external/faust~.pd_linux linux-vdso.so.1 => (0x00007ffe5d9e1000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f50e5c5f000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f50e5a42000) *libstdc++.so.6* => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f50e56c0000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f50e53b7000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f50e51a1000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f50e4dd7000) /lib64/ld-linux-x86-64.so.2 (0x00007f50e8446000) Here is the Github repository: https://github.com/pierreguillot/faust-pd Any help would be greatly appreciated! Thanks, Pierre

1 1

distributing a collection of externals and abstractions using deken
by Joseph Larralde 18 Jun '18

18 Jun '18

Hi list, Apologies if I didn't browse the archives enough before coming here, but I remain with a stupid question. I have a couple of externals I'd like to publish using deken, and the doc is explicit enough to allow me to do this. But, along with these externals, I have some abstractions I've been using for a while and I'd like to "bundle" them with my library. What is the cleanest way to organize my stuff in this case ? For example, I looked at cyclone's repo, where I found a nice way to organize my code, its dependencies and the built objects, as well as a collection of abstractions, but there is neither a .dek file nor an objectlist in there, and I'm not sure about how one would proceed to package it with deken. I guess there must be scripts to achieve this in other existing libraries ... Could anyone please point me to a good example or give me a simple answer ? Thanks, Joseph

4 10

Re: [PD-dev] PD AutoComplete Plugin
by Henri Augusto Bisognini 12 Jun '18

12 Jun '18

On 06/11/2018 15:47 PM, IOhannes m zmölnig wrote: >äh? > you really don't want to autocomplete *that*. I don't even know what that does, i was just looking for stuff with long names haha On 06/11/2018 15:47 PM, IOhannes m zmölnig wrote: > these examples puzzle me a bit, as they are quite the reverse of what i consider "monolithic libraries". > when loading zexy as a multi-object library (aka "monolithic library"), > then there will be *no* [zexy/demultiplex] object, just [demultiplex]. On 06/11/2018 07:11 PM, Henri Augusto Bisognini wrote: > You can find them separately using a special "monolithic search mode" that displays the library name on the completions list but only auto completes the object name (since you can't use namespaces with those). That's why the auto complete shows the library name in the suggestion windows but doesn't type it. For example, you will search for ",demu" ant it will display "zexy/demux" so you know you should load zexy, but when you press enter it will only type demux :) The gif on the readme.md in the repository shows the three search modes in action. On 06/11/2018 15:47 PM, IOhannes m zmölnig wrote: > not sure whether this is directed at me (i don't remember saying anything about performance) Oh, sorry, i forgot to Ctrl+V the text quoting Dan. It should be On 06/10/2018 15:58 PM, Dan Wilcox wrote: > The other aspect is more organizational: how/when do we integrate new things into the pd "core" and keep it maintainable. There is a conscious decision not to put *everything* into to core but some things may > make sense. However I'd suggest *lots* of testing and built-in extensibility before making a formal proposal for it to be adopted. For instance, does this plugin impact GUI performance when patching on slow > machines ie. RPI? I don't know, but it would be good to find out before adding something that would then be *expected* to work well. "About it running on slow computers like Raspberry Pis. What exactly would be the the problem? Processing or memory?" I read on the Netiquette that "Never ever reply to a digested email if you do not refer to exactly one email in the digest." Does that apply to standard emails too? Sorry if that's the case. This mailing list thing is completely new to me. Cheers, Henri. ________________________________ De: Pd-dev <pd-dev-bounces(a)lists.iem.at> em nome de IOhannes m zmölnig <zmoelnig(a)iem.at> Enviado: segunda-feira, 11 de junho de 2018 15:47 Para: pd-dev(a)lists.iem.at Assunto: Re: [PD-dev] PD AutoComplete Plugin On 06/11/2018 07:11 PM, Henri Augusto Bisognini wrote: > zexy/0x3d0x3d0x7e äh? you really don't want to autocomplete *that*. > The only thing it can't do is to read inside those sys dependent files to know what objects are there inside monolithic libraries, like zexy. For that reason it reads a .txt file that the user can set that contains that information. Something like: > > [...] > zexy/atoi > zexy/demultiplex > zexy/demux > these examples puzzle me a bit, as they are quite the reverse of what i consider "monolithic libraries". when loading zexy as a multi-object library (aka "monolithic library"), then there will be *no* [zexy/demultiplex] object, just [demultiplex]. so: are we really talking about the same thing here? > It would definitely be better to communicate with pd directly to query those objects. Is that possible for a GUI plugin? not for a gui-plugin alone. however, you can write "mixed-mode plugins" that consist of a both a gui-plugin and an external (https://git.iem.at/pd-gui/punish/ uses this quite a lot; it's basically a gui-plugin that tells Pd-core to load an external to add the necessary C-parts). > About it running on slow computers like Raspberry Pis. What exactly would be the the problem? Processing or memory? not sure whether this is directed at me (i don't remember saying anything about performance) > Right know the plugin only increases 424kb in RAM usage on my windows computer and i have a reasonable amounts of externals. however, i think that the number of autocompletable objects will only have very little impact on the total RAM used by Pd(gui). i wouldn't worry about the memory foot-print at all :-) gfmdsar IOhannes

2 1

line bug
by cyrille henry 12 Jun '18

12 Jun '18

hello, I made a bug report on github regarding a bug of the line object : When a "stop" message is send after the end of a ramp, the origin of the next ramp is incorrect. This have been introduce with pd 0.48 attachment is a patch that show the problem: line_bug.pd.zip The fix is simple : the x->x_setval should only be set if (clock_getsystime() < x->x_targettime) The correct line_stop function should be : static void line_stop(t_line *x) { if ((pd_compatibilitylevel >= 48) && (pd_compatibilitylevel < 49)) x->x_setval += x->x_1overtimediff * (clock_getsystime() - x->x_prevtime) * (x->x_targetval - x->x_setval); if (pd_compatibilitylevel >= 49) if (clock_getsystime() >= x->x_targettime) x->x_setval = x->x_targetval; else x->x_setval += x->x_1overtimediff * (clock_getsystime() - x->x_prevtime) * (x->x_targetval - x->x_setval); x->x_targetval = x->x_setval; clock_unset(x->x_clock); } (sorry, I have no time for a clean pull request)

1 0

PD AutoComplete Plugin
by Henri Augusto Bisognini 11 Jun '18

11 Jun '18

Hi! It's my first time here! I'm sharing with you a vanilla auto complete plugin. https://github.com/HenriAugusto/PD-AutoComplete-Plugin Right now it needs some testing but in the future i think it would be nice if it could be distributed with vanilla, like deken. That's why i'm starting this thread in the dev-list. I've tested it extensively on my windows machine those last two days but couldn't test in OS X or Linux. Fill an issue on github if you find any bugs. It was based on Yvan Volochine's work that was idle since 2013. I embraced the project and i'm willing to maintain it! Cheers, Henri.)

4 6

Re: [PD-dev] PD AutoComplete Plugin
by Henri Augusto Bisognini 10 Jun '18

10 Jun '18

Yes, definitely! I didn't mean in merging right now. It's an idea for the future. That's why i'm starting this discussion now. To be prepared and take considerations regarding that goal during development and for devs to share their ideas on the subject. Right know the plugin overwrites the pdtk_text_editing proc in pdtk_text.tcl and the script is only triggered when the user presses the Tab key. I'm not 100% about limitations and implications of this. For ex: - what if other plugin by any change also overwrites pdtk_text_editing? (unlikely but possible) - it would be nice that after writing "[send" the auto complete plugin allowed seraching among send/receive names. Such thing was intended by Yvan but in his implementation he could only detect when those names were created. But the user might just delete all [s][r] objects with those names, rename all of them or just close their containing patch. This way the names would still appear as suggestions despite not existing anymore. The names would also be lost between pd sessions. That's why right know i just disabled this feature. So i think i direct communication with pd would be the best way to do this. Would this be possible without integration with PD? It's all on an early stage but just some updates on the current state of testing: -We've been testing the plugin and it reportedly worked in all win 7 machines we've used. -Worked in some linux machines but we found minor problems in others. -(Sierra/Yosemite) The listbox popup doesn't show on OS X right know but the rest of the plugin is working (the user can press up/down and type enter to get a random object, which tells us the underlying code is working) We need more tests in all platforms! Running PD in RPI is more advanced so i guess it will be easier to find people to test it in the mailing lists :) Cheers, Henri. ________________________________ De: Dan Wilcox <danomatika(a)gmail.com> Enviado: domingo, 10 de junho de 2018 15:58 Para: Henri Augusto Bisognini; Alexandre Torres Porres Cc: pd-dev Assunto: Re: [PD-dev] PD AutoComplete Plugin Technically, you can distribute GPL parts as long as they can be freely upgraded/replaced by the user. Since the part in question is a plugin script and not compiled into the Pd binary, it's my understanding that it doesn't infringe upon the library aspect of the GPL and the Pd source is already open. The other aspect is more organizational: how/when do we integrate new things into the pd "core" and keep it maintainable. There is a conscious decision not to put *everything* into to core but some things may make sense. However I'd suggest *lots* of testing and built-in extensibility before making a formal proposal for it to be adopted. For instance, does this plugin impact GUI performance when patching on slow machines ie. RPI? I don't know, but it would be good to find out before adding something that would then be *expected* to work well. On Jun 10, 2018, at 12:00 PM, pd-dev-request(a)lists.iem.at<mailto:pd-dev-request@lists.iem.at> wrote: From: Alexandre Torres Porres <porres(a)gmail.com<mailto:porres@gmail.com>> To: Henri Augusto Bisognini <msndohenri(a)hotmail.com<mailto:msndohenri@hotmail.com>> Cc: "pd-dev(a)lists.iem.at<mailto:pd-dev@lists.iem.at>" <pd-dev(a)lists.iem.at<mailto:pd-dev@lists.iem.at>> Subject: Re: [PD-dev] PD AutoComplete Plugin Message-ID: <CAEAsFmh28zEgiyng92E8SC6XUFfnZLBwOLgXESte4iSrTT2o-A(a)mail.gmail.com<mailto:CAEAsFmh28zEgiyng92E8SC6XUFfnZLBwOLgXESte4iSrTT2o-A@mail.gmail.com>> Content-Type: text/plain; charset="utf-8" OMG, this HAS to be part of the vanilla distribution! I'll definitely test it and check it out. I don't know much about licenses, there wouldn't be a problem to include a GPL tcl code into Vanilla, right? Or would it help if it were BSD? cheers -------- Dan Wilcox @danomatika<http://twitter.com/danomatika> danomatika.com<http://danomatika.com> robotcowboy.com<http://robotcowboy.com>

1 0

Re: [PD-dev] PD AutoComplete Plugin
by Dan Wilcox 10 Jun '18

10 Jun '18

Technically, you can distribute GPL parts as long as they can be freely upgraded/replaced by the user. Since the part in question is a plugin script and not compiled into the Pd binary, it's my understanding that it doesn't infringe upon the library aspect of the GPL and the Pd source is already open. The other aspect is more organizational: how/when do we integrate new things into the pd "core" and keep it maintainable. There is a conscious decision not to put *everything* into to core but some things may make sense. However I'd suggest *lots* of testing and built-in extensibility before making a formal proposal for it to be adopted. For instance, does this plugin impact GUI performance when patching on slow machines ie. RPI? I don't know, but it would be good to find out before adding something that would then be *expected* to work well. > On Jun 10, 2018, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote: > > From: Alexandre Torres Porres <porres(a)gmail.com <mailto:porres@gmail.com>> > To: Henri Augusto Bisognini <msndohenri(a)hotmail.com <mailto:msndohenri@hotmail.com>> > Cc: "pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at>" <pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at>> > Subject: Re: [PD-dev] PD AutoComplete Plugin > Message-ID: > <CAEAsFmh28zEgiyng92E8SC6XUFfnZLBwOLgXESte4iSrTT2o-A(a)mail.gmail.com <mailto:CAEAsFmh28zEgiyng92E8SC6XUFfnZLBwOLgXESte4iSrTT2o-A@mail.gmail.com>> > Content-Type: text/plain; charset="utf-8" > > OMG, this HAS to be part of the vanilla distribution! > > I'll definitely test it and check it out. > > I don't know much about licenses, there wouldn't be a problem to include a > GPL tcl code into Vanilla, right? Or would it help if it were BSD? > > cheers -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

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 June 2018