Re: [PD] wild structs on pd files

Am 08.06.2017 8:49 nachm. schrieb "Miller Puckette" : Yep, if there are "data" in your patch and you remove the "struct" object that defines them, Pd keeps teh objects around anyway, so that you can reclaim them by reloading the "structs" Ah, so this happens when the struct

Re: [PD] lsl_inlet~ now available

LabStreamingLayer’s > On 8 Jun 2017, at 15:35, Roman Haefeli wrote: > > On Don, 2017-06-08 at 13:55 +0200, David Medine wrote: >> For those interested, I pushed onto my github page >> (https://github.com/dmedine/PdLSL/tree/master/lsl_inlet%7E) a Pd >> extern >> that

Re: [PD] vline~ with switch~ off

Hi Miller, maybe I missed something but I think it's at least possible to catch messages to vline~ while DSP is switched off: if the time difference between an incoming float message and the last logical time (updated by the perform routine) is greater then the current block duration, you know

Re: [PD] wild structs on pd files

I totally get what Joao means, I had wondered about that myself. This problems happens for GOP patches which draw scalars on the toplevel canvas. The reclaiming doesn't work if the struct name has a $0. if you reload the abstraction, the $0 will have another value. but here's a solution: you

Re: [PD] soundhack PD externals

no functional change - a couple bugs squashed. mainly i’m just updating them for 64 bit operation on all platforms. also releasing the source code for platforms that i don’t cover (rasp pi). > On Jun 8, 2017, at 10:58 AM, Jugen Frenz wrote: > > that is very kind of you,

Re: [PD] wild structs on pd files

Yep, if there are "data" in your patch and you remove the "struct" object that defines them, Pd keeps teh objects around anyway, so that you can reclaim them by reloading the "structs" later. Put the abstractions back in the patch (or even just load them separately) and you can see the invisible

[PD] wild structs on pd files

Hi again Miller, I had a question regarding structs. When editing my patches in a text editor, I noticed that at the top of the patch there were some "stowaway" structs (and scalars), which can only come from abstractions I used in the main patch - but these abstractions should have the

Re: [PD] soundhack PD externals

that is very kind of you, thank you very much. Do you have any details about what you updated? Thans a lot, Jurgen On 9 June 2017 at 01:54:39, Tom Erbe (soundh...@icloud.com) wrote: I am in the midst of updating the soundhack PD externals. So far, macOS binaries have been compiled as Universal

[PD] soundhack PD externals

I am in the midst of updating the soundhack PD externals. So far, macOS binaries have been compiled as Universal 32/64 bit; and source code for the externals has been uploaded. As soon as I get to a Windows machine (or someone helps me out), I will update those for 64 bit as well. Find them in

Re: [PD] lsl_inlet~ now available

On Don, 2017-06-08 at 13:55 +0200, David Medine wrote: > For those interested, I pushed onto my github page  > (https://github.com/dmedine/PdLSL/tree/master/lsl_inlet%7E)  a Pd > extern  > that wraps LabStreamingLayer's signal inlet. Now you can stream data  > into Pd with LSL. > > This is still

[PD] lsl_inlet~ now available

For those interested, I pushed onto my github page (https://github.com/dmedine/PdLSL/tree/master/lsl_inlet%7E) a Pd extern that wraps LabStreamingLayer's signal inlet. Now you can stream data into Pd with LSL. This is still fairly unpolished. It still crashes sometimes for reasons I don't

Re: [PD] variable outlets in dsp object

Thanks. You do what I'm doing: reassigning the samples out pointers that are stored in the class structure to a local variable in the perform loop. This seems to work better than accessing the stored pointers (on windoze anyway). On 6/8/17 12:36 PM, Pierre Guillot wrote: I don't fully

Re: [PD] variable outlets in dsp object

Or even simpler this code: https://github.com/pierreguillot/pd.dummies/blob/master/src/leeloo_tilde.c 2017-06-08 12:36 GMT+02:00 Pierre Guillot : > I don't fully understand what you do in your code without the rest of it. > I think the simplest approach is to keep all

Re: [PD] variable outlets in dsp object

I don't fully understand what you do in your code without the rest of it. I think the simplest approach is to keep all the DSP information you need in your object's structure(number of samples, pointers to the inlets, pointers to the outlets, etc.) and to call the dsp routine with only your

Re: [PD] variable outlets in dsp object

Now I realize that everything I posted in the last post makes absolutely no sense at all. Something else is causing the crashes. Damn! On 6/8/17 10:51 AM, David Medine wrote: I am writing a DSP extern that can have a any number of outlets depending on the creation arguments (like [fexpr~],

Re: [PD] mtof~ and dbtorms~ in the help files

Please don't just weed them all out. In the past, I have found tables like [dbtorms] very instructive, to show students "the old way we used to do things with lookup tables", or as a visual aid to explaining what a black-box object really does. It would be nice to move them; Maybe into into

[PD] variable outlets in dsp object

I am writing a DSP extern that can have a any number of outlets depending on the creation arguments (like [fexpr~], e.g.). In order to interact with the outlets in the XXX_tilde_perform loop, I made a member of my t_XXX_tilde data structure thus: t_sample **lcl_outs; Then, when I know how

Re: [PD] vline~ with switch~ off

On 06/08/2017 05:21 AM, Miller Puckette wrote: This isn't fixed (and I'm not sure it's fixable)... better use spigots to stop messages from gettingt o vline~s on switched-off windows. cheers Miller Didn't see Miller's answer before I posted mine, sorry.