[PD] cyclone 0.9-0-test for mac (double precision ready) and help compiling

2024-06-12 Thread Alexandre Torres Porres
Hi, I tagged a new release and uploaded 'cyclone 0.9-0-test' to deken for
mac, both single and double precision. I tested here on my intel mac and
all seems fine in both single and double precision Pd. I can't test on
apple silicon though, so I need help testing it please.

I had to fix a couple of things so it would compile for double precision
but I guess I could change and improve the code setting up more variables
with t_float and stuff... but I will leave thar for a bugfix release. As
for release notes, see
https://github.com/porres/pd-cyclone/releases/tag/cyclone_0.9-0

I can compile as I'm used to for windows and linux (and raspberri) with my
virtual machine, but I need help compiling for double precision in this
systems, as my virtual machine script isn't really ready for it. Can anyone
help me with that?

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


[PD] hid for pd64

2024-06-12 Thread Peter P.
Hi dear list,

it seems that [hid] is not available for pd64 on Debian neither via
Deken, nor via apt.

In case anyone is thinking of packaging such binary version, it would be
very welcome!

thanks a lot!
Peter



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


Re: [PD] vanilla drip was Gemwin vs [pix_snap]

2024-06-12 Thread Dan Wilcox
My preference was to avoid creating any interim lists or holding references, 
hence the bang to clear [list store] afterwards. Also, I imagine [list store] 
iterating over the list items is faster.

> On Jun 12, 2024, at 5:23 PM, Benjamin Wesch  wrote:
> 
> hi,
> 
>> I made a vanilla [drip] using [list store], as suggested by IOhannes.
> 
> nice to see these different versions! i attempted to keep it as simple
> as possible (?) a while back based on 3 objects: [list split 1],
> [list( append)] and [t b a] - see attached.
> 
> cheers,
> ben
> 


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


Re: [PD] vanilla drip was Gemwin vs [pix_snap]

2024-06-12 Thread Benjamin Wesch
hi,

> I made a vanilla [drip] using [list store], as suggested by IOhannes.

nice to see these different versions! i attempted to keep it as simple
as possible (?) a while back based on 3 objects: [list split 1],
[list( append)] and [t b a] - see attached.

cheers,
ben


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


[PD] vanilla drip was Gemwin vs [pix_snap]

2024-06-12 Thread Dan Wilcox
Howdy,I made a vanilla [drip] using [list store], as suggested by IOhannes.

l_drip-help.pd
Description: Binary data


l_drip.pd
Description: Binary data
I started updating older list-abs patches I was using to use the newer [list] stufff but I haven't pushed this to GitHub or deken yet.you can also replace [drip] with some patch involving [list store], but that's a bit more complicated.
Dan Wilcoxdanomatika.comrobotcowboy.com

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


Re: [PD] Gemwin vs [pix_snap]

2024-06-12 Thread IOhannes m zmölnig
Am 12. Juni 2024 15:31:24 MESZ schrieb Alexandre Torres Porres 
:
>Em qua., 12 de jun. de 2024 às 04:55, IOhannes m zmoelnig 
>escreveu:
>
>> you can also replace [drip] with some patch involving [list store], but
>> that's a bit more complicated.
>>
>
>it's not, the help file shows how to do it (list iterator example)
>
>

Well, it takes more than just replacing a single object with another (or two 
chained objects)


mfg.sfg.jfd
IOhannes


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


Re: [PD] Gemwin vs [pix_snap]

2024-06-12 Thread Alexandre Torres Porres
Em qua., 12 de jun. de 2024 às 04:55, IOhannes m zmoelnig 
escreveu:

> you can also replace [drip] with some patch involving [list store], but
> that's a bit more complicated.
>

it's not, the help file shows how to do it (list iterator example)


>
> anyhow: the latest and greatest Gem should give you the actual size of
> the framebuffer for your window at the outlet of [gemwin].
> use that instead of the dimension you asked for, and it should fix your
> original problem.
> ([gemwin] outputs all kind of information about the window, so use [route])
>
> gfmasdr
> IOhannes
>
> ___
> 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] [PD-announce] Pd 0.55-0 released

2024-06-12 Thread Alexandre Torres Porres
Em qua., 12 de jun. de 2024 às 06:58, IOhannes m zmoelnig 
escreveu:

> On 6/12/24 11:11, Alexandre Torres Porres wrote:
> > I meant in the puredata.info downloads
>
> these? 
>

yes


> what about them?
>

they weren't there yet when I asked


>
> gsdm
> IOhannes
> ___
> 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] [PD-announce] Pd 0.55-0 released

2024-06-12 Thread IOhannes m zmoelnig

On 6/12/24 11:11, Alexandre Torres Porres wrote:

I meant in the puredata.info downloads


these? 

what about them?

gsdm
IOhannes


OpenPGP_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] [PD-announce] Pd 0.55-0 released

2024-06-12 Thread Alexandre Torres Porres
I meant in the puredata.info downloads

Em qua., 12 de jun. de 2024 às 02:40, IOhannes m zmölnig 
escreveu:

> Am 11. Juni 2024 23:19:23 MESZ schrieb Alexandre Torres Porres <
> por...@gmail.com>:
>
>> Em ter., 11 de jun. de 2024 às 18:05, IOhannes m zmölnig 
>> escreveu:
>>
>>> i've also updated the release page on  to
>>> include the new release.
>>>
>>
>> Nice! What about the double precision version?
>>
>>
> They are part of the flatpak package, and are available as separate
> installation options for Debian resp Ubuntu
>
> mfg.sfg.jfd
> IOhannes
> ___
> 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] Gemwin vs [pix_snap]

2024-06-12 Thread Johnny Mauser via Pd-list
Dear IOhannes,
I stand corrected, framebuffersize is indeed double the size than gemwin:

gemwin: dimen 640 480
gemwin: framebuffersize 1280 960

I will work with this information and see how to change the buffer size..

Thx and sorry for the fast shot!

-jonas

> Am 12.06.2024 um 10:07 schrieb Johnny Mauser :
> 
> Hi IOhannes
> Yeah, I should modernize it, thanks to the hints of objects. 
> Also thanks for the hint of gemwin showing infos on the output. It seems very 
> powerful!!
> Still the weird behavior persists.
> I am using the latest and greatest, I think. I was able to reproduce this 
> behavior with the gemwin help patch, which I added a [pix_snap] + [pix_writer]
> Gemwin tells it is 640x480 still the pix is only 1/4s the content.
> 
> Best,
> -jonas
> 
> 
> 
> 
> 
>> Am 12.06.2024 um 09:53 schrieb IOhannes m zmoelnig :
>> 
>> On 6/12/24 09:25, Johnny Mauser via Pd-list wrote:
>>> Thanks for the answer. Yeah, I was thinking about something like that too, 
>>> don’t know how to track this down. Also I am confused with the gem backends 
>>> these days.
>> 
>> you probably should modernize your patch:
>> - [prepend] -> [list prepend] + [list trim]
>> - [moocow/any2string] -> [fudiformat] (for arbitrary messages) or [list 
>> fromsymbol] (if you only converting a single symbol)
>> those should be simple.
>> you can also replace [drip] with some patch involving [list store], but 
>> that's a bit more complicated.
>> 
>> anyhow: the latest and greatest Gem should give you the actual size of the 
>> framebuffer for your window at the outlet of [gemwin].
>> use that instead of the dimension you asked for, and it should fix your 
>> original problem.
>> ([gemwin] outputs all kind of information about the window, so use [route])
>> 
>> gfmasdr
>> IOhannes
>> 
>> ___
>> 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] Gemwin vs [pix_snap]

2024-06-12 Thread Johnny Mauser via Pd-list
Hi IOhannes
Yeah, I should modernize it, thanks to the hints of objects. 
Also thanks for the hint of gemwin showing infos on the output. It seems very 
powerful!!
Still the weird behavior persists.
I am using the latest and greatest, I think. I was able to reproduce this 
behavior with the gemwin help patch, which I added a [pix_snap] + [pix_writer]
Gemwin tells it is 640x480 still the pix is only 1/4s the content.

Best,
-jonas



pix_writer_test.pd
Description: Binary data




> Am 12.06.2024 um 09:53 schrieb IOhannes m zmoelnig :
> 
> On 6/12/24 09:25, Johnny Mauser via Pd-list wrote:
>> Thanks for the answer. Yeah, I was thinking about something like that too, 
>> don’t know how to track this down. Also I am confused with the gem backends 
>> these days.
> 
> you probably should modernize your patch:
> - [prepend] -> [list prepend] + [list trim]
> - [moocow/any2string] -> [fudiformat] (for arbitrary messages) or [list 
> fromsymbol] (if you only converting a single symbol)
> those should be simple.
> you can also replace [drip] with some patch involving [list store], but 
> that's a bit more complicated.
> 
> anyhow: the latest and greatest Gem should give you the actual size of the 
> framebuffer for your window at the outlet of [gemwin].
> use that instead of the dimension you asked for, and it should fix your 
> original problem.
> ([gemwin] outputs all kind of information about the window, so use [route])
> 
> gfmasdr
> IOhannes
> 
> ___
> 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] Gemwin vs [pix_snap]

2024-06-12 Thread IOhannes m zmoelnig

On 6/12/24 09:25, Johnny Mauser via Pd-list wrote:


Thanks for the answer. Yeah, I was thinking about something like that too, 
don’t know how to track this down. Also I am confused with the gem backends 
these days.



you probably should modernize your patch:
- [prepend] -> [list prepend] + [list trim]
- [moocow/any2string] -> [fudiformat] (for arbitrary messages) or [list 
fromsymbol] (if you only converting a single symbol)

those should be simple.
you can also replace [drip] with some patch involving [list store], but 
that's a bit more complicated.


anyhow: the latest and greatest Gem should give you the actual size of 
the framebuffer for your window at the outlet of [gemwin].
use that instead of the dimension you asked for, and it should fix your 
original problem.

([gemwin] outputs all kind of information about the window, so use [route])

gfmasdr
IOhannes



OpenPGP_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] PD hanging on closing patcher window (when Pd window is closed)

2024-06-12 Thread hans w. koch
hi ediwn,

doesn´t happen here: mac os 14.5. with Pd-0.55-0

(had this issue sometimes in previous versions though, but inconsistently)

best
hans

> Am 12.06.2024 um 08:33 schrieb Edwin van der Heide :
> 
> On macOS 12.7.5 with Pd-0.55-0
> 
> When I open Pure Data, close the Pd window, open a new empty patcher window, 
> and close that patcher window, Pd hangs for me and I only see the icon of the 
> apple menu without the other menu items.
> 
> I don’t think this is a new issue. I am curious if it is reproducible for 
> others.
> 
> Best!
> 
> Edwin
> 
> 
> ___
> 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] Gemwin vs [pix_snap]

2024-06-12 Thread Johnny Mauser via Pd-list
Hi cyrille, 
I am having some trouble sending the patch through gmail. I took away the .zip 
extension and replaced it with .jpg to open it you would need to remove .jpg 
and put .zip back.

Thanks for the answer. Yeah, I was thinking about something like that too, 
don’t know how to track this down. Also I am confused with the gem backends 
these days.

Here is the patch. I hope you have not too much missing dependencies on your 
side, or other trouble opening it.

Thanks,

jonas


> 
>> Am 11.06.2024 um 22:52 schrieb cyrille henry :
>> 
>> hello,
>> The image of the gem windows appear to be 1280x960.
>> pix_snap capture a 640x480 image.
>> Are you sure that the gemwin is create with a dimen of 640x480?
>> Maybe there is a compensation somewhere because of high resolution apple 
>> screen.
>> 
>> can you send your patch?
>> cheers
>> 
>> c
>> 
>> 
>> Le 11/06/2024 à 21:17, Johnny Mauser via Pd-list a écrit :
>>> Dear Lists,
>>> I have an old patch I want to revive and the following problem:
>>> I have a gemwin with certain dimensions, say 640x480pix, and I want to 
>>> record it using [pix_snap]+[pix_writer]. I use the same dimensions for 
>>> pix_snap but it is only capturing the left bottom corner of my gemwin. The 
>>> resulting pix has the correct dimensions, also 640x480pix.
>>> I use macOS 14.4, pd 54.1,
>>> GEM: ver: 0.94.git v0.94-973-g1659d628b
>>> GEM: compiled  on May 23 2024
>>> Here are two pix showing the problem:
>>> Screenshot of Gemwin:
>>> Pix_writer record:
>>> ___
>>> 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] PD hanging on closing patcher window (when Pd window is closed)

2024-06-12 Thread Edwin van der Heide
On macOS 12.7.5 with Pd-0.55-0

When I open Pure Data, close the Pd window, open a new empty patcher window, 
and close that patcher window, Pd hangs for me and I only see the icon of the 
apple menu without the other menu items.

I don’t think this is a new issue. I am curious if it is reproducible for 
others.

Best!

Edwin


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