[PD] clone object - dynamically change number of instances?

2018-03-05 Thread hans w. koch
hello list, 
hello miller,

is there any known way to dynamically change the number of instances associated 
with a clone object, e.g. via message?
i know, the dsp graph would need to be rebulit, but for a project i am 
contemplating that would be less of a concern.

if not, can i suggest this for consideration as a feature request?

thanks for the object anyway, very helpful

hans
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


[PD] avoid "properities"/"open" options in abstractions

2018-03-05 Thread Alexandre Torres Porres
Hi, I'm looking for a way to avoid "properties" from popping up as an
option when right clicking in an abstraction.

This is not really "important", basically only merely aesthetical, as I
want to make abstractions look more closely as compiled objects... but
anyway, please don't judge :)

So, is there a way to do it? Like an external out there? If not, I guess I
need to figure out how to make my own...

Moreover, I'm also after a way to avoid clicking on an abstraction and
opening it, or also even preventing the "open" option from the right click
menu as well.

Thanks
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


Re: [PD] [gemframebuffer] and [pix-film] ... weirdness

2018-03-05 Thread Jack
Le 04/03/2018 à 19:47, oliver a écrit :
> Jack wrote:
>> Hello Oliver,
>>
>> I reduce the patch to expose the problem.
>> The different solutions are inside.
>> Hope it helps...
> 
> it does !
> 
> thanks a lot for your explanation,
> your method also works with the chained shaders !
> 
> even though my ambition was to use one gemhead for everything, i see
> that your preferred solution with a second gemhead is much better and
> also looks more logical to me.
> 
> 
> 
> one last question:
> 
> wouldn't the [pix_buf] method be more cpu intensive ?
> 
> because it says in the help file:
> 
> "[pix_buf] is only effective if it is storing a static image. If you are
> continually modifying the buffered pix, then pix_buf is going to be
> spending a lot of time copying pixels."

If i am right, here there is no [pix_image]/[pix_video]/[pix_film]
before [pix_separator] so there is no risk to buffered pix.
The aim of [pix_separator] in your case is to "isolate" [pix_film] to
the rest of the gemchain like [separator] does about transformations
(that's why I prefer to use two gemchain in your case).
++

Jack


> 
> ... which i think i do when i'm feeding a film into it, isn't it ?
> yet i didn't notice any raised cpu power with [pix_buf] even though i
> used a 1280x720 film.
> 
> 
> 
> best
> 
> oliver
> 
> 
> 
> 
> 
>> ++
>>
>> Jack
>>
>>
>>
>> Le 03/03/2018 à 14:58, oliver a écrit :
>>> Jack wrote:
 Hey Oliver,

 Do you have a minimal patch with a shader that described your problem
>>>
>>>  ... no minimal approach with chained glsl shaders ;-)
>>>
>>> nonetheless, i managed to pack everything together (it's a zipped folder
>>> with all needed ingredients, just a pd patch and the required shader
>>> files) to demonstrate the problem.
>>>
>>> if you can spare the time to take a look at it,
>>> that would be very nice !
>>>
>>> but as i said, i already got my task working with my little hack, so no
>>> sweat, please (even though it "feels" a little fragile).
>>>
>>> best
>>>
>>> oliver
>>>
>>>
>>>
>>>
>>> ___
>>> Pd-list@lists.iem.at mailing list
>>> UNSUBSCRIBE and account-management ->
>>> https://lists.puredata.info/listinfo/pd-list
>>>
>>
>>
>>
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> https://lists.puredata.info/listinfo/pd-list
>>
> 
> 


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


Re: [PD] how to change an object's argument via dynamic patching

2018-03-05 Thread hans w. koch
ok, i see, thanks ayway.

hans

> Am 05.03.2018 um 21:32 schrieb Alexandre Torres Porres :
> 
> 
> 
> 2018-03-05 16:53 GMT-03:00 hans w. koch :
> care to elaborate how?
> 
> not really, this was a stupid problem I was having with a patch, but changed 
> the approach entirely and avoided the whole problem on its own, so I guess it 
> doesn't matter as it basically just made the whole issue I was having 
> pointless.
> 
> as for solutions more closely related to what I wanted, I don't know... maybe 
> [canvasargs] could be used, but I was thinking of something that didn't 
> require externals.
> 
> cheers
>  
> 
> i´d beinterested in a way of dynamically changing number of voices assigned 
> to a “clone” object.
> i am aware, that this will rebuild the dsp graph
> vanilla preferable.
> 
> thanks
> hans
> 
> > Am 05.03.2018 um 17:36 schrieb Alexandre Torres Porres :
> >
> > yeah, this would be quite different, though I can see how using it could do 
> > the trick... but not to worry, as I have found a solution to those 
> > technical issues that didn't need any of this ;) so I guess this is not 
> > important anymore.
> >
> > thanks
> >
> > 2018-03-05 8:14 GMT-03:00 Liam Goodacre :
> > Not dynamic patching, but you can use [canvasargs] from iemguts. Updating 
> > the arguments doesn't happen immediately, but takes effect if the patch is 
> > saved and reloaded.
> >
> > Barring this, I can't think of anything other than the dreaded option of 
> > sending individual mouse and keyboard messages to the canvas.
> > From: Pd-list  on behalf of Alexandre Torres 
> > Porres 
> > Sent: 03 March 2018 03:01
> > To: Pd-List
> > Subject: [PD] how to change an object's argument via dynamic patching
> >
> > Hi, is there a way to change the argument of just one object via dynamic 
> > patching without having to clear all of the patch's or subpatch's object 
> > and restart from scratch?
> >
> > It's not that I'm lazy to clean and restart, I just can't do it, for 
> > technical reasons I don't think it's important to discuss right now.
> >
> > This in Pd Vanilla, of course
> >
> > cheers
> >
> > ___
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management -> 
> > https://lists.puredata.info/listinfo/pd-list
> 
> 


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


Re: [PD] how to change an object's argument via dynamic patching

2018-03-05 Thread hans w. koch
care to elaborate how?

i´d beinterested in a way of dynamically changing number of voices assigned to 
a “clone” object.
i am aware, that this will rebuild the dsp graph
vanilla preferable.

thanks
hans

> Am 05.03.2018 um 17:36 schrieb Alexandre Torres Porres :
> 
> yeah, this would be quite different, though I can see how using it could do 
> the trick... but not to worry, as I have found a solution to those technical 
> issues that didn't need any of this ;) so I guess this is not important 
> anymore.
> 
> thanks
> 
> 2018-03-05 8:14 GMT-03:00 Liam Goodacre :
> Not dynamic patching, but you can use [canvasargs] from iemguts. Updating the 
> arguments doesn't happen immediately, but takes effect if the patch is saved 
> and reloaded.
> 
> Barring this, I can't think of anything other than the dreaded option of 
> sending individual mouse and keyboard messages to the canvas.
> From: Pd-list  on behalf of Alexandre Torres 
> Porres 
> Sent: 03 March 2018 03:01
> To: Pd-List
> Subject: [PD] how to change an object's argument via dynamic patching
>  
> Hi, is there a way to change the argument of just one object via dynamic 
> patching without having to clear all of the patch's or subpatch's object and 
> restart from scratch?
> 
> It's not that I'm lazy to clean and restart, I just can't do it, for 
> technical reasons I don't think it's important to discuss right now.
> 
> This in Pd Vanilla, of course
> 
> cheers
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


Re: [PD] how to change an object's argument via dynamic patching

2018-03-05 Thread Alexandre Torres Porres
yeah, this would be quite different, though I can see how using it could do
the trick... but not to worry, as I have found a solution to those
technical issues that didn't need any of this ;) so I guess this is not
important anymore.

thanks

2018-03-05 8:14 GMT-03:00 Liam Goodacre :

> Not dynamic patching, but you can use [canvasargs] from iemguts. Updating
> the arguments doesn't happen immediately, but takes effect if the patch is
> saved and reloaded.
>
> Barring this, I can't think of anything other than the dreaded option of
> sending individual mouse and keyboard messages to the canvas.
> --
> *From:* Pd-list  on behalf of Alexandre
> Torres Porres 
> *Sent:* 03 March 2018 03:01
> *To:* Pd-List
> *Subject:* [PD] how to change an object's argument via dynamic patching
>
> Hi, is there a way to change the argument of just one object via dynamic
> patching without having to clear all of the patch's or subpatch's object
> and restart from scratch?
>
> It's not that I'm lazy to clean and restart, I just can't do it, for
> technical reasons I don't think it's important to discuss right now.
>
> This in Pd Vanilla, of course
>
> cheers
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


Re: [PD] readsf re-blocked up-sampled

2018-03-05 Thread IOhannes m zmoelnig
On 2018-03-05 12:01, Marco Matteo Markidis wrote:
> In my head the point is: is it usefull to use a [readsf~] in a up-sampled
> subpatch to avoid audio dropout? My idea was to up-sampling and re-blocking
> a subpatch with [readsf~] and pass signal using [outlet~] to the main
> canvas. In this way [readsf~] has a larger blocksize read and it is called
> more often than the main canvas.
i don't think i can follow the logic: how would having a larger
blocksize that is called more often reduce audio dropouts?


if you care about reading larger chunks of the audio-file per block, you
can just re-block the subpatch (without upsampling), and then the signal
sent through [outlet~] will have the correct sample rate (and length,
and pitch).

if you want to replace [soundfiler] with something that takes a little
longer to read a soundfile into a table and therefore avoids dropouts
(because it doesn't have to do all the work in a single DSP tick), you
can use an upsampled (and probably reblocked) subpatch to read the
soundfile with [readsf~], and write it into the table *inside* the
re-blocked canvas.
then access the data from outside (without re-sampling) and the data
will be correct.

fgmasdr
IOhannes



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


Re: [PD] readsf re-blocked up-sampled

2018-03-05 Thread Marco Matteo Markidis
In my head the point is: is it usefull to use a [readsf~] in a up-sampled
subpatch to avoid audio dropout? My idea was to up-sampling and re-blocking
a subpatch with [readsf~] and pass signal using [outlet~] to the main
canvas. In this way [readsf~] has a larger blocksize read and it is called
more often than the main canvas.

Best,
Marco

Ps. I think that the right word is audio dropout/audio interruption and not
glitch. Sorry about that.

2018-03-04 22:19 GMT+01:00 IOhannes m zmölnig :

> On 03/04/2018 09:53 PM, Marco Matteo Markidis wrote:
> > I expect that using [readsf~] in a re-blocked and up-sampled patch is
> > usefull to have the same played back file but trying to avoid glitches.
>
>
> sorry, i'm having trouble parsing that sentence.
>
> anyhow, the sound you get *is* useful and the patch does what it
> announces (that is: it has a subpatch with a different samplerate and
> re-blocking).
>
> if you want your soundfile to be played back at normal speed without
> overlapping, then you play it in a non-reblocked and non-resampled canvas.
> if you need to do something to that sound in a re-blocked and/or
> re-sampled context, then you must send the audio-signal through
> [inlet~]/[outlet~] which will do the re-sampling and re-blocking for you.
>
> mgfdsar
> IOhannes
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>


-- 
Ho cambiato l'indirizzo email in mm.marki...@autistici.org . Se non è un
problema, scrivimi a questo nuovo indirizzo email.

I changed my email address in mm.marki...@autistici.org . If it is ok for
you, please write me to this new email address.
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list