Re: [PD] compiling PD on windows

[Patrice Colet]

Could you post a link to Pd64bit tcl/tk 32bit version? 



Le 20 mars 2018 20:16:52 GMT+01:00, Lucas Cordiviola  a 
écrit :
>Patrice reported he was able to use his 64bit ASIO soundcard only with
>64bit tcl/tk 8.6.8.
>
>He couldn't with 64bit-Pd 32bit-tcl/tk or with Pd-w32
>
>
>--
>
>Mensaje telepatico asistido por maquinas.
>
>On 3/20/2018 5:55 AM, IOhannes m zmoelnig wrote:
>
>On 2018-03-20 08:07, oliver wrote:
>
>
>For a 64bit Pd (still experimental) we also need a 64bit tcl/tk
>
>
>
>could someone explain to me why this is needed?
>
>fgamsdr
>IOhannes
>
>
>
>
>
>___
>Pd-list@lists.iem.at mailing list
>UNSUBSCRIBE and account-management ->
>https://lists.puredata.info/listinfo/pd-list

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] reporting the dimensions of a symbol / float atom

[Liam Goodacre]

The problem is that when I move from one system to another, many of my 
abstractions fail to display correctly, because the atoms fall outside of the 
GOP area. (See the attached image: the GOP area was set in 0.47, but it won't 
display in 0.48). The Context library uses a lot of tightly fitted GOPs (for 
better or worse), and I'm looking for a solution so that I can guarantee that 
they will display correctly on all systems. Even if the PD font width is 
standardized, there is always the chance that somebody loads PD with the 
-font-weight bold flags, which would throw it off again.

An external object that reported the system standard dimensions would offer a 
solution, since you could then set the abstraction to resize itself according 
to the system.

I'm also open to other solutions, if anyone can think of them.

From: Alexandre Torres Porres 
Sent: 20 March 2018 19:43
To: Liam Goodacre
Cc: pd-l...@mail.iem.at
Subject: Re: [PD] reporting the dimensions of a symbol / float atom



2018-03-18 15:09 GMT-03:00 Liam Goodacre 
mailto:liamg...@hotmail.com>>:
 it's just a matter of knowing which variable to call, right?

seems so, I guess we know that much :) but i don't get it, what do you need? 
Font size? That should be simple, and nice/useful cause you could work around 
you patches even if you change a patch's font size.
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] reporting the dimensions of a symbol / float atom

[Roman Haefeli]

On Mit, 2018-03-21 at 13:08 +, Liam Goodacre wrote:
> The problem is that when I move from one system to another, many of
> my abstractions fail to display correctly, because the atoms fall
> outside of the GOP area. (See the attached image: the GOP area was
> set in 0.47, but it won't display in 0.48). The Context library uses
> a lot of tightly fitted GOPs (for better or worse), and I'm looking
> for a solution so that I can guarantee that they will display
> correctly on all systems. Even if the PD font width is standardized,
> there is always the chance that somebody loads PD with the -font-
> weight bold flags, which would throw it off again.
> 
> An external object that reported the system standard dimensions would
> offer a solution, since you could then set the abstraction to resize
> itself according to the system.
> 
> I'm also open to other solutions, if anyone can think of them.

I'm in the same boat. This is the single-most important culprit I
experience with non-consistent font sizes. I think Dan did a great deal
of work to harmonize font and box sizes across platforms.

My strategy has been to wait until things are corrected on the Pd side
instead of trying to work-around those issues myself. So, I hope I can
stick with this strategy, because working-around it is so much work.
Personally, I'd rather have people agree on the notion that this should
be addressed in Pd than people who establish their own ways to mitigate
the problem.

So, if you ask me, please don't use any reporting of sizes ;-)

Is this still an issue with Pd 0.48-1? I thought not, but I might need
to check again.


Roman

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

[PD] changing GOP size dynamically without dirty flag

[Roman Haefeli]

On Mit, 2018-03-21 at 13:08 +, Liam Goodacre wrote:
> An external object that reported the system standard dimensions would
> offer a solution, since you could then set the abstraction to resize
> itself according to the system.

This reminds of my finding, that when using 'donecanvasdialog' to
change the visual size of the GOP area, the abstraction is marked dirty
which leads to more dialogs when closing the patch.

Is there a way to adjust the GOP size without marking the instance of
the abstraction/patch dirty?

Roman

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] changing GOP size dynamically without dirty flag

[oliver]

Is there a way to adjust the GOP size without marking the instance of
the abstraction/patch dirty?



yes, add a "dirty 0" message to the GOP's namecanvas, like this:


put a [namecanvas YOURNAME] onto the patch's top level.


then send it a message like this:

[donecanvasdialog 1 -1 3 0 -1 1 1 100 100 10 10, dirty 0(
|
|
[send YOURNAME]



best

oliver

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

Re: [PD] changing GOP size dynamically without dirty flag

[Roman Haefeli]

On Mit, 2018-03-21 at 14:57 +0100, oliver wrote:
> > 
> > 
> > Is there a way to adjust the GOP size without marking the instance
> > of
> > the abstraction/patch dirty?
>
> [..] send it a message like this:
> 
> [donecanvasdialog 1 -1 3 0 -1 1 1 100 100 10 10, dirty 0(
> |
> [send YOURNAME]


Cool. It's never too late to learn new things. Many thanks :-)

Roman

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] changing GOP size dynamically without dirty flag

[Liam Goodacre]

Another option is the "coords" message. In my mind, this is always preferable 
to "donecanvasdialog" because you don't need to dirty it, and because the 
syntax is slightly easier to remember. If you open the .pd file in a text 
editor, you'll find the "coords" term at the very bottom, and you can work it 
out from there.

From: Pd-list  on behalf of oliver 

Sent: 21 March 2018 13:57
To: pd-l...@mail.iem.at
Subject: Re: [PD] changing GOP size dynamically without dirty flag


>
> Is there a way to adjust the GOP size without marking the instance of
> the abstraction/patch dirty?
>

yes, add a "dirty 0" message to the GOP's namecanvas, like this:


put a [namecanvas YOURNAME] onto the patch's top level.


then send it a message like this:

[donecanvasdialog 1 -1 3 0 -1 1 1 100 100 10 10, dirty 0(
|
|
[send YOURNAME]



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

Re: [PD] reporting the dimensions of a symbol / float atom

[Liam Goodacre]

Thanks for the input, Roman. I followed the discussion bout font sizes, and I 
also appreciate the amount of work that people have put in to solving it. Are 
the font sizes in 0.48.1 considered to be stable? If so, maybe it's time for me 
to cash in and resize everything manually, but I am wary of doing this in case 
things change again...

From: Pd-list  on behalf of Roman Haefeli 

Sent: 21 March 2018 13:46
To: pd-list@lists.iem.at
Subject: Re: [PD] reporting the dimensions of a symbol / float atom

On Mit, 2018-03-21 at 13:08 +, Liam Goodacre wrote:
> The problem is that when I move from one system to another, many of
> my abstractions fail to display correctly, because the atoms fall
> outside of the GOP area. (See the attached image: the GOP area was
> set in 0.47, but it won't display in 0.48). The Context library uses
> a lot of tightly fitted GOPs (for better or worse), and I'm looking
> for a solution so that I can guarantee that they will display
> correctly on all systems. Even if the PD font width is standardized,
> there is always the chance that somebody loads PD with the -font-
> weight bold flags, which would throw it off again.
>
> An external object that reported the system standard dimensions would
> offer a solution, since you could then set the abstraction to resize
> itself according to the system.
>
> I'm also open to other solutions, if anyone can think of them.

I'm in the same boat. This is the single-most important culprit I
experience with non-consistent font sizes. I think Dan did a great deal
of work to harmonize font and box sizes across platforms.

My strategy has been to wait until things are corrected on the Pd side
instead of trying to work-around those issues myself. So, I hope I can
stick with this strategy, because working-around it is so much work.
Personally, I'd rather have people agree on the notion that this should
be addressed in Pd than people who establish their own ways to mitigate
the problem.

So, if you ask me, please don't use any reporting of sizes ;-)

Is this still an issue with Pd 0.48-1? I thought not, but I might need
to check again.


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

Re: [PD] pad sound with Pd

[Julian Brooks]

Blimey just checked that youtube link. 'Wowsah' indeed, great tune!

On 20 March 2018 at 21:54, Roman Haefeli  wrote:

> On Die, 2018-03-20 at 22:09 +0100, Dan Wilcox wrote:
> > Try s_pad in rjlib: https://github.com/rjdj/rjlib
>
> Oh yeah. There's a lot that can be tweaked with this one. Will have to
> try it out in a polyphony setup. Anyway, there are a lot of interesting
> sounds to check out. Thanks for pointing me to it (I already had it
> installed).
>
> > Or ask this guy 0_O https://www.youtube.com/watch?v=T2Y0ftqDUlE
>
> Yeah, I saw this one. Amazing!
>
> 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

Re: [PD] reporting the dimensions of a symbol / float atom

[Dan Wilcox]

More less, except for Windows which is not using DejaVu Sans Mono yet, although 
we have a font loader for it now. This should be fixed in an upcoming version.

The sizing is taken from Pd-extended which largely had tested Tcl font 
rendering across all platforms. With the same font, the patches should render 
the same size most everywhere, as shown with our testing. I would still suggest 
not relying on *exact* pixel sizes and give yourself a little padding here and 
there to be safe.

In some ways, this was really not a fun problem as people moving from 
Pd-extended had broken sizing and people with tight GUIs like yourself have 
broken patches, but it should be *much* easier to resolve the sizing in the 
future. OTOH maybe it's worth talking about a different sizing algorithm and/or 
object size querying as setting a different font will of course change the 
sizing slightly base on what TK gives us. Maybe being able to query the size 
and width a character in the current font might help...

> On Mar 21, 2018, at 3:18 PM, pd-list-requ...@lists.iem.at wrote:
> 
> From: Liam Goodacre mailto:liamg...@hotmail.com>>
> To: "pd-list@lists.iem.at " 
> mailto:pd-list@lists.iem.at>>
> Subject: Re: [PD] reporting the dimensions of a symbol / float atom
> Message-ID:
>   
>   
> >
>   
> Content-Type: text/plain; charset="utf-8"
> 
> Thanks for the input, Roman. I followed the discussion bout font sizes, and I 
> also appreciate the amount of work that people have put in to solving it. Are 
> the font sizes in 0.48.1 considered to be stable? If so, maybe it's time for 
> me to cash in and resize everything manually, but I am wary of doing this in 
> case things change again...


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] compiling PD on windows

[Lucas Cordiviola]

Here is your original mail. It contains a working link to an "Pd64bit tcl/tk 
32bit"


https://lists.puredata.info/pipermail/pd-list/2018-01/121423.html


Mensaje telepatico asistido por maquinas.

On 3/21/2018 6:07 AM, Patrice Colet wrote:

Could you post a link to Pd64bit tcl/tk 32bit version?



Le 20 mars 2018 20:16:52 GMT+01:00, Lucas Cordiviola 
 a écrit :

Patrice reported he was able to use his 64bit ASIO soundcard only with 64bit 
tcl/tk 8.6.8.

He couldn't with 64bit-Pd 32bit-tcl/tk or with Pd-w32


--

Mensaje telepatico asistido por maquinas.

On 3/20/2018 5:55 AM, IOhannes m zmoelnig wrote:

On 2018-03-20 08:07, oliver wrote:


For a 64bit Pd (still experimental) we also need a 64bit tcl/tk


could someone explain to me why this is needed?

fgamsdr
IOhannes





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



--
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.

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

Re: [PD] reporting the dimensions of a symbol / float atom

[Dan Wilcox]

The atoms are slightly taller due to the increase in inlet height to match 
Pd-extended's sizing.

> On Mar 21, 2018, at 7:52 PM, pd-list-requ...@lists.iem.at wrote:
> 
> From: Liam Goodacre mailto:liamg...@hotmail.com>>
> Cc: Pd-List mailto:pd-list@lists.iem.at>>
> Subject: Re: [PD] reporting the dimensions of a symbol / float atom
> Message-ID:
>   
>   
> >
>   
> Content-Type: text/plain; charset="utf-8"
> 
> It would certainly help me to have be able to query atom sizes. Beyond the 
> issue of tight GOP areas, in Context you can resize atoms dynamically (see 
> the attached gif). The whole thing rests on knowing the basic dimensions of 
> an atom. If there is a margin of error here, then the whole thing gets thrown 
> off.
> 
> I'll grant that this is an unusual case, but it seems likely that many other 
> users could benefit from a system which sizes GOPs and canvases according to 
> font units. Roman, I don't see this getting in the way of any future 
> solution--it's more just an optional feature which would enhance 
> compatibility between older and newer versions of PD, many of which will 
> remain in use for a long time.
> 
> BTW, we are talking about two different things here: font size and atom size. 
> What is the relationship between them? In 0.48.1, the atom appears to have 
> increased in height, suggesting that they are not always proportional.


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] reporting the dimensions of a symbol / float atom

[Roman Haefeli]

On Mit, 2018-03-21 at 18:52 +, Liam Goodacre wrote:
> It would certainly help me to have be able to query atom sizes. 

I see your point and the benefit of such a feature. Independent of
that, I'd like to be able to count on consistent box sizes across
platforms and future Pd versions. 

> BTW, we are talking about two different things here: font size and
> atom size. What is the relationship between them? In 0.48.1, the atom
> appears to have increased in height, suggesting that they are not
> always proportional.

Right. I was assuming those would be related, but my main concern is
about box size, exactly because of fitting atoms into GOP areas.

Roman



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] reporting the dimensions of a symbol / float atom

[rolfm]

 Dan Wilcox wrote:


The atoms are slightly taller due to the increase in inlet height to
match Pd-extended's sizing.



on my windows 10 it's the opposite;
the new one is smaller.
hereby i re-send the picture in which the new object box is upon the 
older one.


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

Re: [PD] compiling PD on windows

[rolfm]

my ultimate goal is to be able to compile on an older machine with XP.

to get experience i first tried on Windows 10.

installed MSYS2 etc (following Dan's instructions on the GITHUB page.

start MSYS2, cd to the src folder of Vanilla 48.1, and do

make


which gives me the error: /bin/sh: cl: opdracht niet gevonden (== 
command not found).


(screenshot attached).


the same happens when i try to use Visual Studio 2015.

the VCSDK & VC9 are present in my system, so is the cl.exe.

my conclusion: somehow the makefile which should work for Windows 
doesn't fit with my system.


but i don't know what to do about it.

any suggestion?


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

[PD] cannot 'upgrade' old patch

[rolfm]

hi list,

i have old patches made with Pdext 42.5.
when opened with Vanilla 48.1 i get lots of uncreated objects (of 
course).


some of them i'm not able to 'repair'.
e.g. [symbol2list]

i put in a [declare -stdpath -zexy -stdlib -zexy].
it's possible to create a new [symbol2list] object.

after saving, closing pd, opening again,
the new object is not created.

what can i do to resolve this.

rolf

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