Re: [PD] expr / expr~

[Alexandre Torres Porres]

2017-04-08 23:26 GMT-03:00 Matt Davey :

> quick questions...
>
>
> (1) these finally got a nice open license, like pd?
>

yes, and it is now part of the Pd Binary (not an external in "extra" no
more)


>
> (2) if they did, can all their functionality be properly documented in
> help files, etc?
>

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

[PD] expr / expr~

[Matt Davey]

quick questions...


(1) these finally got a nice open license, like pd?

(2) if they did, can all their functionality be properly documented in help
files, etc?
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] switch~ default off?

[Matt Davey]

i've always been annoyed that [switch~] is off by default.

could we at least get a creation argument to turn it on???

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

Re: [PD] Deken install path & permissions on Debian

[Julian Brooks]

Just for clarification.

I made a /home/julian/.local/lib/pd/extra/ directory, clicked on a lib via
deken, dl'd it, and all works lovely
(apart from having libs scattered across my computer:)

Julian

On 7 April 2017 at 23:45, Julian Brooks  wrote:

> Apologies IOhannes, I was a little hasty with my celebrations.
>
> After installing the pd-deken packages I still get this from Pd when
> attempting to install a lib:
> "No writeable directory found in:
> - /home/julian/.local/lib/pd/extra/
> - /home/julian/pd-externals
> - /usr/local/lib/pd-externals
> - /usr/lib/puredata/extra
> - /usr/lib/pd/extra
> Cannot download/install libraries!"
>
> Pd-0.47.1 ("") compiled for Debian (0.47.1-3)
> Debian Sid (up to date)
>
> Hi Alexandre, well for me the folders already created (/usr/lib/pd/extra)
> by the Debian Pd install, it's getting the libs in there that's the current
> issue.
> But yes, which folder that should definitively be is still also up for
> debate I guess.
>
> Julian
>
>
>
> On 7 April 2017 at 17:13, Alexandre Torres Porres 
> wrote:
>
>> > Brilliant that deken can sort all this very soon
>>
>> maybe for linux? how is it? you cant write externals in the application
>> specific folder so it'll offer that one and write it?
>>
>> since you can write externals in the application specific folder in mac,
>> it won't offer it, and maybe that could happen in some linux
>> distribution/set up?
>>
>> things would really be sorted if the folders were just created once and
>> for all...
>>
>> cheers
>>
>> 2017-04-07 7:08 GMT-03:00 Julian Brooks :
>>
>>> Hi Roman,
>>>
>>> Yeah, I'd spotted the
>>> ~/.local/lib/pd/extra
>>> as being canonical from an earlier thread but as 1. I didn't already
>>> have that folder 2. historically (dangerous I know) the non-hidden path had
>>> always been 'the place' for externals, so I just blithely carried on
>>> regardless - ouch(blush).
>>>
>>> All below meant with the utmost respect for the work currently being
>>> done...
>>>
>>> Doesn't this just cause more issues? While I can conceptualise the
>>> reasoning for differing usr/lib/puredata (vanilla install) and usr/lib/pd
>>> folders - it is another added layer of confusion for newbs (not meant as a
>>> pejorative).
>>> Obfuscating externals in hidden folders seems unnecessary (and yes, I'm
>>> aware I brought 'canonical' into it /.worms/can of/argh).
>>>
>>> I'm not familiar enough with other linux flavours to know this but
>>> certainly on debian I have no other ~/.folders on my system, even though
>>> the non-hidden path already exists via the apt install (and there's a ton
>>> of other programs' 'stuff' in /usr/lib/).
>>> So for me I'd vote for consistency, not one folder with externals via
>>> apt and another via deken (as well as the vanilla 'extra') - it's too
>>> confusing.
>>>
>>> Of course I'm not necessarily saying that there should only be a 'one
>>> approach fits all' for all linux flavours (that's not how we roll) but then
>>> again it might save lots of people lots of headaches if it was simple,
>>> doable and clear across the board (I'm not including Win and Mac here
>>> obviously - they've got their own issues). Well, actually having reread
>>> that line _-_ ok, I guess that is what I'm saying then - "one method to
>>> rule them all".
>>> Certainly for writing documentation this would make things so much
>>> easier.
>>>
>>> Brilliant that deken can sort all this very soon but for those of us
>>> stuck in an eternal 'now' we could do with a solution, or at least a
>>> consistent conceptual approach:)
>>>
>>> Andy - mooove along please (and yes, I've just added it to my
>>> .bashrc:D
>>>
>>> Regards,
>>>
>>> Julian
>>>
>>> On 7 April 2017 at 10:03, Roman Haefeli  wrote:
>>>
 On Don, 2017-04-06 at 21:12 +0100, Julian Brooks wrote:
 >
 >
 > Now of course I can just dl whatever lib via deken, save it somewhere
 > within where I do have permissions and cp it to the right place but
 > I'm lazy at heart - plus for 'how-to's this is a more complex
 > description - how are others doing it?

 On Linux, the "correct" path (a.k.a the user specific search path) is
 ~/.local/lib/pd/extra. Just use Deken to download there directly. If
 the folder already exists, Deken will suggest it as the first option.
 There is no need to copy things around.

 NOTE: You still have to create that directory manually. However,
 upcoming versions of Pd will include a Deken that automatically creates
 that folder if you chose so.

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


>>>
>>> ___
>>> Pd-list@lists.iem.at mailing list
>>> UNSUBSCRIBE and account-management -> 

Re: [PD] [Gem] Modifying single pixel of pix image

[cyrille henry]

hello,
I use ping "pong buffer" frequentlly : using 2 framebuffer is a good way to go.

There is an exemple in 10.glsl/07.framebuffer_and_shader : I use a "ping pong" 
to create the wave physical model.

For your application, you don't even need a shader to alter the image : you can 
draw the image, then draw a pixel size square where you want to modify it.

c


Le 08/04/2017 à 10:51, Christof Ressi a écrit :

You could also experiment with fragment shader + "ping pong" framebuffers:

shaders usually don't have 'memory' of the last frame(s), so the idea is that 
you have two framebuffers and *alternately* take one's texture as input and 
draw to the other framebuffer. this way you can work on the previous frame and 
manipulate the alpha channel, e.g. subtract values from your alpha pixels based 
on some random function etc. You can define some uniforms to control the 
parameters of your decay formula from outside.

Framebuffer ping ponging is easy in openFrameworks, but I have never done it in 
GEM (honestly I haven't used GEM for a long time now). I guess you can use two 
[gemframebuffer] objects and switch your connections every other frame...



Gesendet: Samstag, 08. April 2017 um 10:32 Uhr
Von: "Christof Ressi" 
An: "Roman Haefeli" 
Cc: pd-list 
Betreff: Re: [PD] [Gem] Modifying single pixel of pix image

That's funny, I just did exactly this recently, but in openFrameworks. If you 
want to do it entirely in GL (which will be fastest), this is how I did it:

start with a white framebuffer and gradually draw black stuff in there. Don't 
clear the framebuffer so it accumulates. You can even draw with alpha blending 
to make the decomposition smooth. Then simply use the texture of the 
framebuffer as the alpha mask for your image texture.

I couldn't see how to do GL alpha masking in GEM but you can easily write a 
little shader which takes the two textures as uniforms, then you would just 
need to take one channel of the mask texture and copy it to the alpha channel 
of your image texture.

You can also try on the CPU level: create your mask in a table, make it to a 
greyscale image and use pix_takealpha to copy your alpha mask to your image 
pixels. Of course, this will be much slower.

You can also mix the two approaches: create the mask on the CPU and do actually 
masking in GL.

Hope that helps!



Gesendet: Samstag, 08. April 2017 um 10:02 Uhr
Von: "Roman Haefeli" 
An: pd-list 
Betreff: Re: [PD] [Gem] Modifying single pixel of pix image

On Sam, 2017-04-08 at 08:29 +0200, Christof Ressi wrote:

If it can be on the GPU, use a fragment shader! Do you work with a
formula or do you set the alpha values by hand?


By Hand (maybe later by a formula). Is it possible?

The idea is to have two overlaying images. The visible one slowly
decomposes over time so that the image behind appears. I thought about
setting alpha to for more and more pixels as a way to decompose the
front image. Maybe there is another/better way?

Roman



Gesendet: Freitag, 07. April 2017 um 23:39 Uhr
Von: "Roman Haefeli" 
An: pd-list@lists.iem.at
Betreff: [PD] [Gem] Modifying single pixel of pix image

Hi

Is it possible to manipulate a single pixel of a an image loaded by
[pix_image]? Specifically, I'd like to change the alpha value of
certain pixels. It doesn't matter to me whether the manipulation
happens in the pix realm or the GL realm. Currently I can think
only of
cumbersome ways like using [pix_dump] -> [pix_set] and applying the
manipulation to the largish list passed between them. Or by using
[pix_pix2sig~] -> [pix_sig2pix~] which is basically the same, but
would
allow to do the manipulation on a table.

Roman
 ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/l
istinfo/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



___
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] [Gem] Modifying single pixel of pix image

[Christof Ressi]

You could also experiment with fragment shader + "ping pong" framebuffers:

shaders usually don't have 'memory' of the last frame(s), so the idea is that 
you have two framebuffers and *alternately* take one's texture as input and 
draw to the other framebuffer. this way you can work on the previous frame and 
manipulate the alpha channel, e.g. subtract values from your alpha pixels based 
on some random function etc. You can define some uniforms to control the 
parameters of your decay formula from outside.

Framebuffer ping ponging is easy in openFrameworks, but I have never done it in 
GEM (honestly I haven't used GEM for a long time now). I guess you can use two 
[gemframebuffer] objects and switch your connections every other frame...


> Gesendet: Samstag, 08. April 2017 um 10:32 Uhr
> Von: "Christof Ressi" 
> An: "Roman Haefeli" 
> Cc: pd-list 
> Betreff: Re: [PD] [Gem] Modifying single pixel of pix image
>
> That's funny, I just did exactly this recently, but in openFrameworks. If you 
> want to do it entirely in GL (which will be fastest), this is how I did it: 
> 
> start with a white framebuffer and gradually draw black stuff in there. Don't 
> clear the framebuffer so it accumulates. You can even draw with alpha 
> blending to make the decomposition smooth. Then simply use the texture of the 
> framebuffer as the alpha mask for your image texture.
> 
> I couldn't see how to do GL alpha masking in GEM but you can easily write a 
> little shader which takes the two textures as uniforms, then you would just 
> need to take one channel of the mask texture and copy it to the alpha channel 
> of your image texture.
> 
> You can also try on the CPU level: create your mask in a table, make it to a 
> greyscale image and use pix_takealpha to copy your alpha mask to your image 
> pixels. Of course, this will be much slower.
> 
> You can also mix the two approaches: create the mask on the CPU and do 
> actually masking in GL.
> 
> Hope that helps!
> 
> 
> > Gesendet: Samstag, 08. April 2017 um 10:02 Uhr
> > Von: "Roman Haefeli" 
> > An: pd-list 
> > Betreff: Re: [PD] [Gem] Modifying single pixel of pix image
> >
> > On Sam, 2017-04-08 at 08:29 +0200, Christof Ressi wrote:
> > > If it can be on the GPU, use a fragment shader! Do you work with a
> > > formula or do you set the alpha values by hand?
> > 
> > By Hand (maybe later by a formula). Is it possible?
> > 
> > The idea is to have two overlaying images. The visible one slowly
> > decomposes over time so that the image behind appears. I thought about
> > setting alpha to for more and more pixels as a way to decompose the
> > front image. Maybe there is another/better way?
> > 
> > Roman
> > 
> > 
> > > > Gesendet: Freitag, 07. April 2017 um 23:39 Uhr
> > > > Von: "Roman Haefeli" 
> > > > An: pd-list@lists.iem.at
> > > > Betreff: [PD] [Gem] Modifying single pixel of pix image
> > > > 
> > > > Hi
> > > > 
> > > > Is it possible to manipulate a single pixel of a an image loaded by
> > > > [pix_image]? Specifically, I'd like to change the alpha value of
> > > > certain pixels. It doesn't matter to me whether the manipulation
> > > > happens in the pix realm or the GL realm. Currently I can think
> > > > only of
> > > > cumbersome ways like using [pix_dump] -> [pix_set] and applying the
> > > > manipulation to the largish list passed between them. Or by using
> > > > [pix_pix2sig~] -> [pix_sig2pix~] which is basically the same, but
> > > > would
> > > > allow to do the manipulation on a table.
> > > > 
> > > > Roman 
> > > >  ___
> > > > Pd-list@lists.iem.at mailing list
> > > > UNSUBSCRIBE and account-management -> https://lists.puredata.info/l
> > > > istinfo/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
>

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

Re: [PD] [Gem] Modifying single pixel of pix image

[Christof Ressi]

That's funny, I just did exactly this recently, but in openFrameworks. If you 
want to do it entirely in GL (which will be fastest), this is how I did it: 

start with a white framebuffer and gradually draw black stuff in there. Don't 
clear the framebuffer so it accumulates. You can even draw with alpha blending 
to make the decomposition smooth. Then simply use the texture of the 
framebuffer as the alpha mask for your image texture.

I couldn't see how to do GL alpha masking in GEM but you can easily write a 
little shader which takes the two textures as uniforms, then you would just 
need to take one channel of the mask texture and copy it to the alpha channel 
of your image texture.

You can also try on the CPU level: create your mask in a table, make it to a 
greyscale image and use pix_takealpha to copy your alpha mask to your image 
pixels. Of course, this will be much slower.

You can also mix the two approaches: create the mask on the CPU and do actually 
masking in GL.

Hope that helps!


> Gesendet: Samstag, 08. April 2017 um 10:02 Uhr
> Von: "Roman Haefeli" 
> An: pd-list 
> Betreff: Re: [PD] [Gem] Modifying single pixel of pix image
>
> On Sam, 2017-04-08 at 08:29 +0200, Christof Ressi wrote:
> > If it can be on the GPU, use a fragment shader! Do you work with a
> > formula or do you set the alpha values by hand?
> 
> By Hand (maybe later by a formula). Is it possible?
> 
> The idea is to have two overlaying images. The visible one slowly
> decomposes over time so that the image behind appears. I thought about
> setting alpha to for more and more pixels as a way to decompose the
> front image. Maybe there is another/better way?
> 
> Roman
> 
> 
> > > Gesendet: Freitag, 07. April 2017 um 23:39 Uhr
> > > Von: "Roman Haefeli" 
> > > An: pd-list@lists.iem.at
> > > Betreff: [PD] [Gem] Modifying single pixel of pix image
> > > 
> > > Hi
> > > 
> > > Is it possible to manipulate a single pixel of a an image loaded by
> > > [pix_image]? Specifically, I'd like to change the alpha value of
> > > certain pixels. It doesn't matter to me whether the manipulation
> > > happens in the pix realm or the GL realm. Currently I can think
> > > only of
> > > cumbersome ways like using [pix_dump] -> [pix_set] and applying the
> > > manipulation to the largish list passed between them. Or by using
> > > [pix_pix2sig~] -> [pix_sig2pix~] which is basically the same, but
> > > would
> > > allow to do the manipulation on a table.
> > > 
> > > Roman 
> > >  ___
> > > Pd-list@lists.iem.at mailing list
> > > UNSUBSCRIBE and account-management -> https://lists.puredata.info/l
> > > istinfo/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] [Gem] Modifying single pixel of pix image

[Roman Haefeli]

On Sam, 2017-04-08 at 08:29 +0200, Christof Ressi wrote:
> If it can be on the GPU, use a fragment shader! Do you work with a
> formula or do you set the alpha values by hand?

By Hand (maybe later by a formula). Is it possible?

The idea is to have two overlaying images. The visible one slowly
decomposes over time so that the image behind appears. I thought about
setting alpha to for more and more pixels as a way to decompose the
front image. Maybe there is another/better way?

Roman


> > Gesendet: Freitag, 07. April 2017 um 23:39 Uhr
> > Von: "Roman Haefeli" 
> > An: pd-list@lists.iem.at
> > Betreff: [PD] [Gem] Modifying single pixel of pix image
> > 
> > Hi
> > 
> > Is it possible to manipulate a single pixel of a an image loaded by
> > [pix_image]? Specifically, I'd like to change the alpha value of
> > certain pixels. It doesn't matter to me whether the manipulation
> > happens in the pix realm or the GL realm. Currently I can think
> > only of
> > cumbersome ways like using [pix_dump] -> [pix_set] and applying the
> > manipulation to the largish list passed between them. Or by using
> > [pix_pix2sig~] -> [pix_sig2pix~] which is basically the same, but
> > would
> > allow to do the manipulation on a table.
> > 
> > Roman 
> >  ___
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management -> https://lists.puredata.info/l
> > istinfo/pd-list
> > 

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [Gem] Modifying single pixel of pix image

[Christof Ressi]

If it can be on the GPU, use a fragment shader! Do you work with a formula or 
do you set the alpha values by hand?

> Gesendet: Freitag, 07. April 2017 um 23:39 Uhr
> Von: "Roman Haefeli" 
> An: pd-list@lists.iem.at
> Betreff: [PD] [Gem] Modifying single pixel of pix image
>
> Hi
> 
> Is it possible to manipulate a single pixel of a an image loaded by
> [pix_image]? Specifically, I'd like to change the alpha value of
> certain pixels. It doesn't matter to me whether the manipulation
> happens in the pix realm or the GL realm. Currently I can think only of
> cumbersome ways like using [pix_dump] -> [pix_set] and applying the
> manipulation to the largish list passed between them. Or by using
> [pix_pix2sig~] -> [pix_sig2pix~] which is basically the same, but would
> allow to do the manipulation on a table.
> 
> Roman 
>  ___
> 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