date:20200529

Em sex., 29 de mai. de 2020 às 23:22, Miller Puckette via Pd-announce <
pd-annou...@lists.iem.at> escreveu:

> To Pd-announce:
>
> Pd 0.51-0test2 is up.  It should fix the code signing problem in test1 ofr
> Macintoshes.


More precisely, Macs on Catalina.

For me, it still asks to throw pd into the trash the 1st time I try to open
it, but I guess that's life now, and I still find it takes longes to load
externals and patches.

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

[PD] [PD-announce] pd 0.51-0test2 for Macontosh - another try at code signing

2020-05-29 Thread Miller Puckette via Pd-announce

To Pd-announce:

Pd 0.51-0test2 is up.  It should fix the code signing problem in test1 ofr
Macintoshes.  No difference from test1 on other OSes.

http://msp.ucsd.edu/software.htm

cheers
Miller




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

Re: [PD] Catalina makes Pd take too long to load externals? + Other annoyances.

2020-05-29 Thread IOhannes m zmölnig

On 5/29/20 6:57 PM, Miller Puckette via Pd-list wrote:
> Hmm - this (PR 838) should be merged in master and incorporated in the
> 0.51-0test1 build - if it isn't I need to go back and try again.

it looks pretty merged to me.

fgmafds
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] Catalina makes Pd take too long to load externals? + Other annoyances.

2020-05-29 Thread Miller Puckette via Pd-list

Hmm - this (PR 838) should be merged in master and incorporated in the
0.51-0test1 build - if it isn't I need to go back and try again.


thanks
Miller

On Fri, May 29, 2020 at 12:35:45PM +0200, Dan Wilcox wrote:
> Y'all: I fixed this months go, it's just not in the current builds (but now 
> in the current master):
> 
> https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/838__;!!Mih3wA!UQwdIzVSKzWPtymTfwjr43dh2Qci2fKxBeJFDwZUtWa9YftFdGy0gBJjt3JU$
>   
>   >
> 
> Someone sent an email to pd-dev about it, I fixed it, and they tested the 
> fix. If you want to test on Catalina, try the "Pd-0.52-2-signed.zip" on 
> https://urldefense.com/v3/__http://docs.danomatika.com/pdbuilds/0.51/__;!!Mih3wA!UQwdIzVSKzWPtymTfwjr43dh2Qci2fKxBeJFDwZUtWa9YftFdGy0gLMFcAPx$
>   
>   >
> 
> Also, everyone please stop the constant FUD about forced upgrades. We get it, 
> you use the OS you prefer and I will use the one I prefer.
> 
> > On May 29, 2020, at 11:41 AM, pd-list-requ...@lists.iem.at wrote:
> > 
> > Date: Fri, 29 May 2020 11:34:21 +0200
> > From: "hans w. koch" mailto:hansw.k...@gmail.com>>
> > To: Pd-List mailto:pd-list@lists.iem.at>>
> > Subject: Re: [PD] Catalina makes Pd take too long to load externals? +
> > Other annoyances.
> > Message-ID: <2778dcc4-504e-4afa-afec-93d3f6068...@gmail.com 
> > >
> > Content-Type: text/plain;   charset=utf-8
> > 
> > (had replied to this earlier, but to alexandre only, by mistake.)
> > 
> > that annoying behaviour is called notarization and should protect the 
> > galaxy from evil bananas.
> > the delay could be caused by the notarization process checking against an 
> > internal database of good actors and in case there is no entry trying to do 
> > so online.
> > i??ve heard you can kill all this by turning off SIP (sytem integrity 
> > protection), but i am on mojave, which is slightly less annoying.
> > 
> > in addittion, if some brave soul on cataline wants to check if that 
> > assumption about notarization is true, there is some info here:
> > https://urldefense.com/v3/__https://forums.developer.apple.com/thread/117896__;!!Mih3wA!UQwdIzVSKzWPtymTfwjr43dh2Qci2fKxBeJFDwZUtWa9YftFdGy0gH7ottHq$
> >   
> >  >  >
> > so the test would be to measure with and without that stuff???but thats 
> > certainly not a generally recommandable case.
> > 
> > best
> > hans
> 
> 
> Dan Wilcox
> @danomatika 
>   >
> danomatika.com 
>   >
> robotcowboy.com 
>   >
> 
> 
> 

> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!!Mih3wA!UQwdIzVSKzWPtymTfwjr43dh2Qci2fKxBeJFDwZUtWa9YftFdGy0gBoDsURC$
>  




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

Re: [PD] Font scaling on Linux

Em sex., 29 de mai. de 2020 às 14:22, Christof Ressi 
escreveu:

> they should finally look the same on all systems.
>

well, almost the same :)
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Font scaling on Linux

Somewhere between 0.47 and 0.50 the font rendering has been unified 
across Windows, macOS and Linux. Patches might look a bit different than 
before, but the important thing is that they should finally look the 
same on all systems.


Christof

On 29.05.2020 18:45, Nicola Pandini wrote:

Hi list,
I've read on this list about font scaling issues on linux.
What I'm experiencing is a difference in font and box height between 
Pure Data 0.47.1 (Debian Stretch + tk8.6.6) and Pure Data 0.50.2 
(Debian Buster + tk8.6.9) both of two systems have DejaVu installed 
properly.
To put it simple, boxes and fonts are taller in 0.50.2 and that cause 
my patches to be messed up.
I tried to play with font_metric values in pd-gui.tcl, without notable 
results.

I'd like to know if someone has found a solution for this behaviour.

Thanks


___
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] Catalina makes Pd take too long to load externals? + Other annoyances.

Em sex., 29 de mai. de 2020 às 13:05, Dan Wilcox 
escreveu:

> If you have an Apple Developer account, you can download old versions of
> Xcode
>

that's a great tip, thanks, but I don't have and wouldn't like to pay for
that
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Catalina makes Pd take too long to load externals? + Other annoyances.

Em sex., 29 de mai. de 2020 às 07:35, Dan Wilcox 
escreveu:

> Y'all: I fixed this months go, it's just not in the current builds (but
> now in the current master):
>
> https://github.com/pure-data/pure-data/pull/838
>

just let me get it straight, so it's still not working in the build for
0.50-1-test1 but it's gonna be alright when the final release is out? I
trust you have a working build, but I'm just worried that the future
official downloads will be fine.

Em sex., 29 de mai. de 2020 às 09:06, Christof Ressi 
escreveu:

> I don't really see how Windows or macOS force anyone to upgrade the OS.
>
My macOS example. I formatted and tested Catalina, cool, went back to
Mojave, which is screwed up as you need to find a torrent download from
pirate bay for that but ok... then I tried to install XCode in Mojave, and
"app store" then tells me I need to upgrade to Catalina in order to
download XCode, cause it can't be downloaded to Mojave.

I need XCode to compile Pd and my externals, I was forced to upgrade to
Catalina... and I cried...

I might find a way to get a torrent from pirate bay maybe that allows me to
install XCode in mojave? I dunno...

> Software improves and new software builds on top on that. That's just how
it works.

It takes a while though, and the current problems with Pd and Catalina are
really bumming me out. Also, I sometimes open Pd Extended to test something
from old days... and Catalina finally put a nail to that coffin.

> Are *we* forcing people to upgrade to the latest Pd version because we
don't backport features and bugfixes to Pd 0.34?

I always "force push" people to install the very latest Pd Vanilla quite
immediately for my patches, tutorials and externals, but I hope this is not
frowned upon in this list :)

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

Re: [PD] Catalina makes Pd take too long to load externals? + Other annoyances.

2020-05-29 Thread Dan Wilcox

If you have an Apple Developer account, you can download old versions of Xcode 
back to 3.0 or so. You have to login to the developer site and find the 
Downloads section.

> On May 29, 2020, at 6:02 PM, Alexandre Torres Porres  wrote:
> 
> I need XCode to compile Pd and my externals, I was forced to upgrade to 
> Catalina... and I cried...
> 
> I might find a way to get a torrent from pirate bay maybe that allows me to 
> install XCode in mojave? I dunno...


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 



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

Re: [PD] [GEM] output gemwin to video file workaround using ffmpeg on macos

2020-05-29 Thread Johnny Mauser via Pd-list

For me on OSX syphon + syphon recorder works best.

Antoine Villeret  schrieb am Fr., 29. Mai 2020,
10:54:

> Hi,
>
> what about using a screen casting tool ? they are usually made for gaming
> and thus optimized for real time performance.
> On macos, quicktime player is a pretty simple solution for that.
> The only drawback I saw is that you're stuck with the rendering window
> size since the tool grab a part of the screen, you can't render at a bigger
> resolution than the display's one.
>
> My 2 cents
>
> A
>
> Le ven. 29 mai 2020 à 10:05, cyrille henry  a écrit :
>
>> hello,
>> The open GL rendering is made in the GPU. grabbing the images by the CPU
>> in order to compress them and to record them in the HDD is a slow operation.
>> I think some software are able to compress the image in the GPU in order
>> to grab a smaller file, but Gem don't.
>> So, there is not a lot's of solution, and you already found them.
>>
>> I use pix_record when I need a correct quality of a small video. I use
>> mjpa with good result.
>>
>> When I need better quality, I use pix_writer. Usually this can not be
>> made in real time. I.E : I create a process that render exactly what I
>> want, without human interaction. (For live performance, I record all human
>> interaction in tables or texts file during the performance, then I use this
>> data to play again the same performance)
>> Then, It's possible to record both image annd sound in the same time.
>> Even if pd will not be sync with real (external) time, the time inside pd
>> will still stay consistent. I.E : even if there are lot's of audio dropout
>> and the recording fps is 1/2 of the real fps, pd will still record a
>> perfect audio file that will be perfectly sync with the video. You just
>> need to start the audio and video recording with the same "bang".
>>
>>
>> cheers
>> Cyrille
>>
>> Le 28/05/2020 à 22:33, ffdd cchh a écrit :
>> > Hi everyone,
>> >
>> > Is it possible to grab the OpenGL stream with ffmpeg and save to a
>> video file? If so, could anyone point in the right direction as to how to
>> capture the stream opened by Gem?
>> >
>> > The reason I ask this is that I am looking for ways to render video
>> frames to a file and I have not managed a good result using neither
>> [pix_record] nor [pix_writer].
>> >
>> > With [pix_record] I have systematically tried all codecs and
>> colorspaces and I had no luck.
>> >
>> > With [pix_writer], I did manage high quality frames with the correct
>> colorspace which I then concatenated into a video (with ffmpeg). The
>> drawback I have with [pix_writer] is the time it takes to write, which
>> really complicates audio and video synching.
>> >
>> > Thanks!!
>> >
>> > Fede
>> > --
>> > fdch.github.io 
>> >
>> > ___
>> > 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] Catalina makes Pd take too long to load externals? + Other annoyances.


Also, everyone please stop the constant FUD about forced upgrades.

+1



I don't really see how Windows or macOS force anyone to upgrade the OS. 
You can still use your favourite 20 year OS, just don't expect to get 
security updates or run recent software.


Are *we* forcing people to upgrade to the latest Pd version because we 
don't backport features and bugfixes to Pd 0.34?


Software improves and new software builds on top on that. That's just 
how it works.


Now, backwards compatibility is a whole different story. Breaking 
changes or feature removal might indeed force users to upgrade their 
software. Actually, Windows and macOS differ a lot in this regard. I 
kind of understand both sides, but I have my personal preference ;-)




Christof

On 29.05.2020 12:35, Dan Wilcox wrote:
Y'all: I fixed this months go, it's just not in the current builds 
(but now in the current master):


https://github.com/pure-data/pure-data/pull/838

Someone sent an email to pd-dev about it, I fixed it, and they tested 
the fix. If you want to test on Catalina, try the 
"Pd-0.52-2-signed.zip" on http://docs.danomatika.com/pdbuilds/0.51/


Also, everyone please stop the constant FUD about forced upgrades. We 
get it, you use the OS you prefer and I will use the one I prefer.


On May 29, 2020, at 11:41 AM, pd-list-requ...@lists.iem.at 
 wrote:


Date: Fri, 29 May 2020 11:34:21 +0200
From: "hans w. koch" mailto:hansw.k...@gmail.com>>
To: Pd-List mailto:pd-list@lists.iem.at>>
Subject: Re: [PD] Catalina makes Pd take too long to load externals? +
Other annoyances.
Message-ID: <2778dcc4-504e-4afa-afec-93d3f6068...@gmail.com 
>

Content-Type: text/plain;charset=utf-8

(had replied to this earlier, but to alexandre only, by mistake.)

that annoying behaviour is called notarization and should protect the 
galaxy from evil bananas.
the delay could be caused by the notarization process checking 
against an internal database of good actors and in case there is no 
entry trying to do so online.
i´ve heard you can kill all this by turning off SIP (sytem integrity 
protection), but i am on mojave, which is slightly less annoying.


in addittion, if some brave soul on cataline wants to check if that 
assumption about notarization is true, there is some info here:

https://forums.developer.apple.com/thread/117896
so the test would be to measure with and without that stuff…but thats 
certainly not a generally recommandable case.


best
hans



Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 




___
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] Catalina makes Pd take too long to load externals? + Other annoyances.

2020-05-29 Thread Dan Wilcox

Y'all: I fixed this months go, it's just not in the current builds (but now in 
the current master):

https://github.com/pure-data/pure-data/pull/838 


Someone sent an email to pd-dev about it, I fixed it, and they tested the fix. 
If you want to test on Catalina, try the "Pd-0.52-2-signed.zip" on 
http://docs.danomatika.com/pdbuilds/0.51/ 


Also, everyone please stop the constant FUD about forced upgrades. We get it, 
you use the OS you prefer and I will use the one I prefer.

> On May 29, 2020, at 11:41 AM, pd-list-requ...@lists.iem.at wrote:
> 
> Date: Fri, 29 May 2020 11:34:21 +0200
> From: "hans w. koch" mailto:hansw.k...@gmail.com>>
> To: Pd-List mailto:pd-list@lists.iem.at>>
> Subject: Re: [PD] Catalina makes Pd take too long to load externals? +
>   Other annoyances.
> Message-ID: <2778dcc4-504e-4afa-afec-93d3f6068...@gmail.com 
> >
> Content-Type: text/plain; charset=utf-8
> 
> (had replied to this earlier, but to alexandre only, by mistake.)
> 
> that annoying behaviour is called notarization and should protect the galaxy 
> from evil bananas.
> the delay could be caused by the notarization process checking against an 
> internal database of good actors and in case there is no entry trying to do 
> so online.
> i´ve heard you can kill all this by turning off SIP (sytem integrity 
> protection), but i am on mojave, which is slightly less annoying.
> 
> in addittion, if some brave soul on cataline wants to check if that 
> assumption about notarization is true, there is some info here:
> https://forums.developer.apple.com/thread/117896 
> 
> so the test would be to measure with and without that stuff…but thats 
> certainly not a generally recommandable case.
> 
> best
> hans


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 



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

Re: [PD] [PD-announce] Pd 0.51-0 test 1 released

2020-05-29 Thread Jack

Hello list,

Thanks Miller and all other people involved for this new release !
++

Jack



Le 28/05/2020 à 22:08, Miller Puckette via Pd-announce a écrit :
> To Pd-announce:
> 
> Pd version 0.51-0test1 is available on http://msp.ucsd.edu/software.htm
> or (source only) via github: https://github.com/pure-data/pure-data
> 
> The "older machine" compile targets aren't ready yet, just 64-bit ones for
> OSes less than 10 or 15 years old.
> 
> 
> 
> ___
> Pd-announce mailing list
> pd-annou...@lists.iem.at
> https://lists.puredata.info/listinfo/pd-announce
> ___
> 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.51-0 test 1 released

thanks for nudging my laziness…i´ll give it a spin :-)

hans

> Am 29.05.2020 um 11:31 schrieb Christof Ressi :
> 
>> so far i compiled nicolas danets “spaghettis” pd fork 
>> (https://github.com/Spaghettis/Spaghettis), but i guess its now time to try 
>> and compile pd myself.
>> unless some kind and more knowledgable soul provides a binary for mac, hint, 
>> hint :-)
> If you managed to compile "spaghettis" from source, than compiling Pd should 
> be no big deal. Did you give it a try? The INSTALL.txt contains the necessary 
> info.
> 
> Christof
> 
> On 29.05.2020 11:25, hans w. koch wrote:
>> thanks, christof,
>> 
>> that makes sense.
>> a more general question: is that the plan for a transisiton period or will 
>> it stay that way for the foreseeable future?
>> 
>> apart from the obvious profits for the playback of longer soundfiles and the 
>> ones specified in katjas research some time ago 
>> (http://www.katjaas.nl/doubleprecision/doubleprecision.html),
>> i use double for simple math tasks involving really big numbers.
>> 
>> so far i compiled nicolas danets “spaghettis” pd fork 
>> (https://github.com/Spaghettis/Spaghettis), but i guess its now time to try 
>> and compile pd myself.
>> unless some kind and more knowledgable soul provides a binary for mac, hint, 
>> hint :-)
>> (dan wilcox did one for pd50-2 some time ago)
>> 
>> best
>> hans
>> 
>>> Am 29.05.2020 um 10:48 schrieb Christof Ressi :
>>> 
>>> Hi Hans,
>>> 
>>> it means that Pd can be compiled -DPD_FLOATSIZE=64, so it will use 64-bit 
>>> doubles instead of 32-bit floats everywhere, and all built-in objects 
>>> should still work as expected.
>>> 
>>> This has advantages (better precision/stability for certain filters, large 
>>> precise table indicies, etc.) and possible disadvantages (needs more 
>>> memory, some code paths might be a bit slower).
>>> 
>>> Currently, we only ship the good old single precision builds, but people 
>>> can compile double precision builds from source for themselves to 
>>> experiment with.
>>> 
>>> Christof
>>> 
>>> On 29.05.2020 08:58, hans w. koch wrote:
 excited about that release, thanks to all involved!
 
> * maybe mention that Pd is now double precision ready?
 what does that exactly mean? is it in, but not enabled or is it a subset?
 ( certainly its not a marketing scam as these tv sets labeled “HD ready” 
 :-)
 
 thanks for clarification,
 
 hans
>>> 
>>> 
>>> ___
>>> 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] Catalina makes Pd take too long to load externals? + Other annoyances.

(had replied to this earlier, but to alexandre only, by mistake.)

that annoying behaviour is called notarization and should protect the galaxy 
from evil bananas.
the delay could be caused by the notarization process checking against an 
internal database of good actors and in case there is no entry trying to do so 
online.
i´ve heard you can kill all this by turning off SIP (sytem integrity 
protection), but i am on mojave, which is slightly less annoying.

in addittion, if some brave soul on cataline wants to check if that assumption 
about notarization is true, there is some info here:
https://forums.developer.apple.com/thread/117896
so the test would be to measure with and without that stuff…but thats certainly 
not a generally recommandable case.

best
hans

> Am 29.05.2020 um 10:42 schrieb Christof Ressi :
> 
> 
>> Not sure if this is a Pd thing or just something stupid that macOS now does 
>> for ALL applications. 
> https://appleinsider.com/articles/19/12/23/apple-will-enforce-app-notarization-for-macos-catalina-in-february
> 
> Welcome to macOS Catalina :-)
> 
> Christof
> 
> On 29.05.2020 03:16, Alexandre Torres Porres wrote:
>> Hey macOS/Catalina people (do we have any here?), I formatted my computer 
>> and decided to install Catalina just to test things and now I can't go back. 
>> I was forced to stay in the latest release because I can't install XCode 
>> from app store in the previous OS, it has to be Catalina... Miller is right 
>> to hate mac and windows force pushing upgrades <3 - I might still try to go 
>> back and install XCode somehow cause I'm starting to hate a few things - 
>> enough ranting!
>> 
>> Anyway, I already opened an issue that seems to affect Catalina - 
>> https://github.com/pure-data/pure-data/issues/988 - but for that tcl/tk 
>> might be the one to hate for. As long as we're at it, do other Catalina 
>> users have the same issue there?
>> 
>> Now for the actual subject of the email. I'm finding that externals in 
>> Catalina are taking too long to load. Anyone else feels that? It's kind of 
>> intermittent. Sometimes it does that, sometimes not... it's happening for me 
>> in Pd 0.50-2 and the new 0.51-0-test1 as well.
>> 
>> As for yet another annoyance, Catalina will now say it can't open Pd right 
>> out of the box when you download, and it'll even ask you if you want to 
>> delete. It does this even if you right click and ask to open it. Previously, 
>> you had to right click and ask to open so it would give you an option "do 
>> you really want to open this?". Now it just says something like 
>> 
>> "“Pd-0.50-2” cannot be opened because the developer cannot be verified.
>> 
>> macOS cannot verify that this app is free from malware.
>> 
>> Chrome downloaded this file today at 22:05 from msp.ucsd.edu." 
>> 
>> It's only when you say cancel and try that for a SECOND time is that if 
>> offers you the possibility to open if you really really want it and changes 
>> the warning to macOS cannot verify the developer of “Pd-0.50-2”. Are you 
>> sure you want to open it?. Not sure if this is a Pd thing or just something 
>> stupid that macOS now does for ALL applications. 
>> 
>> 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




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

Re: [PD] [PD-announce] Pd 0.51-0 test 1 released


so far i compiled nicolas danets “spaghettis” pd fork 
(https://github.com/Spaghettis/Spaghettis), but i guess its now time to try and 
compile pd myself.
unless some kind and more knowledgable soul provides a binary for mac, hint, 
hint :-)
If you managed to compile "spaghettis" from source, than compiling Pd 
should be no big deal. Did you give it a try? The INSTALL.txt contains 
the necessary info.


Christof

On 29.05.2020 11:25, hans w. koch wrote:

thanks, christof,

that makes sense.
a more general question: is that the plan for a transisiton period or will it 
stay that way for the foreseeable future?

apart from the obvious profits for the playback of longer soundfiles and the 
ones specified in katjas research some time ago 
(http://www.katjaas.nl/doubleprecision/doubleprecision.html),
i use double for simple math tasks involving really big numbers.

so far i compiled nicolas danets “spaghettis” pd fork 
(https://github.com/Spaghettis/Spaghettis), but i guess its now time to try and 
compile pd myself.
unless some kind and more knowledgable soul provides a binary for mac, hint, 
hint :-)
(dan wilcox did one for pd50-2 some time ago)

best
hans


Am 29.05.2020 um 10:48 schrieb Christof Ressi :

Hi Hans,

it means that Pd can be compiled -DPD_FLOATSIZE=64, so it will use 64-bit 
doubles instead of 32-bit floats everywhere, and all built-in objects should 
still work as expected.

This has advantages (better precision/stability for certain filters, large 
precise table indicies, etc.) and possible disadvantages (needs more memory, 
some code paths might be a bit slower).

Currently, we only ship the good old single precision builds, but people can 
compile double precision builds from source for themselves to experiment with.

Christof

On 29.05.2020 08:58, hans w. koch wrote:

excited about that release, thanks to all involved!


* maybe mention that Pd is now double precision ready?

what does that exactly mean? is it in, but not enabled or is it a subset?
( certainly its not a marketing scam as these tv sets labeled “HD ready” :-)

thanks for clarification,

hans



___
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] [PD-announce] Pd 0.51-0 test 1 released

thanks, christof,

that makes sense.
a more general question: is that the plan for a transisiton period or will it 
stay that way for the foreseeable future?

apart from the obvious profits for the playback of longer soundfiles and the 
ones specified in katjas research some time ago 
(http://www.katjaas.nl/doubleprecision/doubleprecision.html),
i use double for simple math tasks involving really big numbers. 

so far i compiled nicolas danets “spaghettis” pd fork 
(https://github.com/Spaghettis/Spaghettis), but i guess its now time to try and 
compile pd myself.
unless some kind and more knowledgable soul provides a binary for mac, hint, 
hint :-)
(dan wilcox did one for pd50-2 some time ago)

best
hans

> Am 29.05.2020 um 10:48 schrieb Christof Ressi :
> 
> Hi Hans,
> 
> it means that Pd can be compiled -DPD_FLOATSIZE=64, so it will use 64-bit 
> doubles instead of 32-bit floats everywhere, and all built-in objects should 
> still work as expected.
> 
> This has advantages (better precision/stability for certain filters, large 
> precise table indicies, etc.) and possible disadvantages (needs more memory, 
> some code paths might be a bit slower).
> 
> Currently, we only ship the good old single precision builds, but people can 
> compile double precision builds from source for themselves to experiment with.
> 
> Christof
> 
> On 29.05.2020 08:58, hans w. koch wrote:
>> excited about that release, thanks to all involved!
>> 
>>> * maybe mention that Pd is now double precision ready?
>> what does that exactly mean? is it in, but not enabled or is it a subset?
>> ( certainly its not a marketing scam as these tv sets labeled “HD ready” :-)
>> 
>> thanks for clarification,
>> 
>> hans
> 
> 
> 
> ___
> 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] output gemwin to video file workaround using ffmpeg on macos

2020-05-29 Thread Antoine Villeret

Hi,

what about using a screen casting tool ? they are usually made for gaming
and thus optimized for real time performance.
On macos, quicktime player is a pretty simple solution for that.
The only drawback I saw is that you're stuck with the rendering window size
since the tool grab a part of the screen, you can't render at a bigger
resolution than the display's one.

My 2 cents

A

Le ven. 29 mai 2020 à 10:05, cyrille henry  a écrit :

> hello,
> The open GL rendering is made in the GPU. grabbing the images by the CPU
> in order to compress them and to record them in the HDD is a slow operation.
> I think some software are able to compress the image in the GPU in order
> to grab a smaller file, but Gem don't.
> So, there is not a lot's of solution, and you already found them.
>
> I use pix_record when I need a correct quality of a small video. I use
> mjpa with good result.
>
> When I need better quality, I use pix_writer. Usually this can not be made
> in real time. I.E : I create a process that render exactly what I want,
> without human interaction. (For live performance, I record all human
> interaction in tables or texts file during the performance, then I use this
> data to play again the same performance)
> Then, It's possible to record both image annd sound in the same time. Even
> if pd will not be sync with real (external) time, the time inside pd will
> still stay consistent. I.E : even if there are lot's of audio dropout and
> the recording fps is 1/2 of the real fps, pd will still record a perfect
> audio file that will be perfectly sync with the video. You just need to
> start the audio and video recording with the same "bang".
>
>
> cheers
> Cyrille
>
> Le 28/05/2020 à 22:33, ffdd cchh a écrit :
> > Hi everyone,
> >
> > Is it possible to grab the OpenGL stream with ffmpeg and save to a video
> file? If so, could anyone point in the right direction as to how to capture
> the stream opened by Gem?
> >
> > The reason I ask this is that I am looking for ways to render video
> frames to a file and I have not managed a good result using neither
> [pix_record] nor [pix_writer].
> >
> > With [pix_record] I have systematically tried all codecs and colorspaces
> and I had no luck.
> >
> > With [pix_writer], I did manage high quality frames with the correct
> colorspace which I then concatenated into a video (with ffmpeg). The
> drawback I have with [pix_writer] is the time it takes to write, which
> really complicates audio and video synching.
> >
> > Thanks!!
> >
> > Fede
> > --
> > fdch.github.io 
> >
> > ___
> > 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] [PD-announce] Pd 0.51-0 test 1 released


Hi Hans,

it means that Pd can be compiled -DPD_FLOATSIZE=64, so it will use 
64-bit doubles instead of 32-bit floats everywhere, and all built-in 
objects should still work as expected.


This has advantages (better precision/stability for certain filters, 
large precise table indicies, etc.) and possible disadvantages (needs 
more memory, some code paths might be a bit slower).


Currently, we only ship the good old single precision builds, but people 
can compile double precision builds from source for themselves to 
experiment with.


Christof

On 29.05.2020 08:58, hans w. koch wrote:

excited about that release, thanks to all involved!


* maybe mention that Pd is now double precision ready?

what does that exactly mean? is it in, but not enabled or is it a subset?
( certainly its not a marketing scam as these tv sets labeled “HD ready” :-)

thanks for clarification,

hans




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

Re: [PD] Catalina makes Pd take too long to load externals? + Other annoyances.

Not sure if this is a Pd thing or just something stupid that macOS now
does for ALL applications.

https://appleinsider.com/articles/19/12/23/apple-will-enforce-app-notarization-for-macos-catalina-in-february

Welcome to macOS Catalina :-)

Christof

On 29.05.2020 03:16, Alexandre Torres Porres wrote:
Hey macOS/Catalina people (do we have any here?), I formatted my
computer and decided to install Catalina just to test things and now I
can't go back. I was forced to stay in the latest release because I
can't install XCode from app store in the previous OS, it has to be
Catalina... Miller is right to hate mac and windows force pushing
upgrades <3 - I might still try to go back and install XCode somehow
cause I'm starting to hate a few things - enough ranting!

Anyway, I already opened an issue that seems to affect Catalina -
https://github.com/pure-data/pure-data/issues/988 - but for that
tcl/tk might be the one to hate for. As long as we're at it, do other
Catalina users have the same issue there?

*Now for the actual subject of the email. I'm finding that externals
in Catalina are taking too long to load. Anyone else feels that? It's
kind of intermittent. Sometimes it does that, sometimes not... it's
happening for me in Pd 0.50-2 and the new 0.51-0-test1 as well.*

*
*
As for yet another annoyance, Catalina will now say it can't open Pd
right out of the box when you download, and it'll even ask you if you
want to delete. It does this even if you right click and ask to open
it. Previously, you had to right click and ask to open so it would
give you an option "do you really want to open this?". Now it just
says something like

"“Pd-0.50-2” cannot be opened because the developer cannot be verified.

macOS cannot verify that this app is free from malware.

Chrome downloaded this file today at 22:05 from msp.ucsd.edu
."

It's only when you say cancel and try that for a SECOND time is that
if offers you the possibility to open if you really really want it and
changes the warning to *macOS cannot verify the developer of
“Pd-0.50-2”. Are you sure you want to open it?*. Not sure if this is a
Pd thing or just something stupid that macOS now does for ALL
applications.

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] [GEM] output gemwin to video file workaround using ffmpeg on macos

2020-05-29 Thread cyrille henry


hello,
The open GL rendering is made in the GPU. grabbing the images by the CPU in 
order to compress them and to record them in the HDD is a slow operation.
I think some software are able to compress the image in the GPU in order to 
grab a smaller file, but Gem don't.
So, there is not a lot's of solution, and you already found them.

I use pix_record when I need a correct quality of a small video. I use mjpa 
with good result.

When I need better quality, I use pix_writer. Usually this can not be made in 
real time. I.E : I create a process that render exactly what I want, without 
human interaction. (For live performance, I record all human interaction in 
tables or texts file during the performance, then I use this data to play again 
the same performance)
Then, It's possible to record both image annd sound in the same time. Even if pd will not 
be sync with real (external) time, the time inside pd will still stay consistent. I.E : 
even if there are lot's of audio dropout and the recording fps is 1/2 of the real fps, pd 
will still record a perfect audio file that will be perfectly sync with the video. You 
just need to start the audio and video recording with the same "bang".


cheers
Cyrille

Le 28/05/2020 à 22:33, ffdd cchh a écrit :

Hi everyone,

Is it possible to grab the OpenGL stream with ffmpeg and save to a video file? 
If so, could anyone point in the right direction as to how to capture the 
stream opened by Gem?

The reason I ask this is that I am looking for ways to render video frames to a 
file and I have not managed a good result using neither [pix_record] nor 
[pix_writer].

With [pix_record] I have systematically tried all codecs and colorspaces and I 
had no luck.

With [pix_writer], I did manage high quality frames with the correct colorspace 
which I then concatenated into a video (with ffmpeg). The drawback I have with 
[pix_writer] is the time it takes to write, which really complicates audio and 
video synching.

Thanks!!

Fede
--
fdch.github.io 

___
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.51-0 test 1 released