Re: [PD] [text] editor window line numbers?

[Liam Goodacre]

What about prepending the line numbers on the way into [text]?



From: Pd-list  on behalf of Derek Kwan 

Sent: 05 December 2016 03:48
To: pd-list@lists.iem.at
Subject: [PD] [text] editor window line numbers?

Hi list,

Is there an "easy" way of getting line numbers in the editor window for
[text] (the one that pops up with the "click" method), perhaps via tcl
plugin or adding/editing methods in pdtk_textwindow.tcl? It'd be
particularly helpful in jumping to specific line numbers when using
[text sequence]. Thanks!
--
Derek Kwan
www.derekxkwan.com
derek kwan | percussionist / electronic artist
www.derekxkwan.com
website of percussionist and computer programmer Derek Kwan



___
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] [text] editor window line numbers?

[Derek Kwan]

Hi list,

Is there an "easy" way of getting line numbers in the editor window for
[text] (the one that pops up with the "click" method), perhaps via tcl
plugin or adding/editing methods in pdtk_textwindow.tcl? It'd be
particularly helpful in jumping to specific line numbers when using
[text sequence]. Thanks!
-- 
Derek Kwan
www.derekxkwan.com

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

Re: [PD] cyclone comment and cross platform (was Re: Purr Data rc1)

[Jonathan Wilkes via Pd-list]

> The character is not invisible. In an editor it manifests with an endline 
> plus an indentation in the following line which actually visually helps parse 
> things out inside a plaintext file like .pd.
 

 I think the example you mentioned, while possible, is contrived because if a 
user is reading a config, they are likely already inside Pd with the intention 
of using such a config to configure their patch state. If this is the case, and 
the config is stored inside a patch in a form of a comment, then this is a 
non-issue because all \v chars are replaced with \n at runtime which IIRC 
regexp and similar methodologies can recognize as a separation between args. 
Now, the only reason I can imagine someone parsing a pd file without actually 
loading it would be your pd META example for tooltips which is a one-off 
example that can be easily addressed in a number of ways. Other examples seem 
to me like academic exercises--why would you store config inside a comments 
inside a pd patch, just to parse a comment which would require you to 
circumnavigate all the other syntax inside the file when you could do the same 
in a plaintext file or a coll object, or better yet, use preset_hub/node 
system? 
I agree that '\v' is a small inconsistency, but it's an inconsistency 
nonetheless.  
I worry about it getting used a model more than anything else.
This mostly comes after seeing the warnings in core Pd, and noticing that the 
same class of warnings is replicated throughout nearly all of the external 
libraries.
 
-Jonathan

> Best, Ico
  
 On 12/4/2016 2:38 PM, Jonathan Wilkes wrote:
  
   
 
> What about people parsing Pd files in Pd?  If they're searching for 
symbol "foo", are they going to have to deal with the edge case of symbol 
"foo\v"? 
  Ivica, Just to give an example-- suppose someone is using a 
patch to store configuration data for their project.  They type the config data 
as comments in the 
  patch, much like [pd META].  Then they parse their patch from within Pd, 
using [textfile], or [text] or  whatever.
  
  Now, if they decide to insert some newlines into the comments to make their 
config prettier, as far as I understand this ends up appending an invisible 
  '\v' character to the last atom of each line.  So the next time they read 
their config they will get corrupted data that's hard to debug because  the 
  character doing the corruption is non-printable. 
   That's the only direct downside I can see.  But as a design pattern it's 
problematic-- there are other places in Pd where a dev tried to  use an 
  "obscure" character as a placeholder for something else.  That approach 
usually ends up creating more bugs. 
  -Jonathan
   
 
 

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

Re: [PD] Scrolling/panning window from Pd

[João Pais]

To make things clearer, I should have written "canvas" instead of "window".
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] Scrolling/panning window from Pd

[João Pais]

Hello list,

I wanted to know if someone ever managed to make a Pd window scroll (or
pan) using a Pd patch, or a plugin that is activated by Pd. I don't know
enough from Tcl/Tk to try it myself.

Best,

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

Re: [PD] cyclone comment and cross platform (was Re: Purr Data rc1)

[Alexandre Torres Porres]

2016-12-03 23:27 GMT-02:00 Jonathan Wilkes :

> Why not just use the built-in  comment?
>


So, why use cyclone/comment instead of pd’s comment?

It does offer advantages as it is, such as setting a different font type,
different font size and colors. It is still not updated  to the latest
version of Max 4, let alone up to Max 7, so it can be improved by including
other functionalities, such as background color. We didn’t touch it yet and
I was hoping to at least include a properties window as it’d be the
sensible thing to do with it.


I’ve been finding it very useful, and I can see advantages to have it in
vanilla even if you could use labels with spaces in there, such as not
having any canvas background or being able to break the text into different
lines.

Why keep distributing cyclone/comment in cyclone? Well, cause it was there
before…

Now, we have some issues with it.

In the cyclone development end, we find it is not behaving well in cross
platforms, we need to fix this! We haven’t really tried it yet… and we’re
not sure where to look.

In the Purr Data end, it is not yet ported, and it is the only object in
cyclone that doesn’t load yet.

So, my idea would be to maybe start a new cyclone/comment for Purr Data,
having it’s ability to use spaces in GUI’s labels as a starting point.
Somewhere in this process, it’d be good to come up with also a working
external, that doesn’t look weird in Linux, for the cyclone package release.


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

Re: [PD] cyclone comment and cross platform (was Re: Purr Data rc1)

[Ivica Ico Bukvic]

The character is not invisible. In an editor it manifests with an 
endline plus an indentation in the following line which actually 
visually helps parse things out inside a plaintext file like .pd.


I think the example you mentioned, while possible, is contrived because 
if a user is reading a config, they are likely already inside Pd with 
the intention of using such a config to configure their patch state. If 
this is the case, and the config is stored inside a patch in a form of a 
comment, then this is a non-issue because all \v chars are replaced with 
\n at runtime which IIRC regexp and similar methodologies can recognize 
as a separation between args.


Now, the only reason I can imagine someone parsing a pd file without 
actually loading it would be your pd META example for tooltips which is 
a one-off example that can be easily addressed in a number of ways. 
Other examples seem to me like academic exercises--why would you store 
config inside a comments inside a pd patch, just to parse a comment 
which would require you to circumnavigate all the other syntax inside 
the file when you could do the same in a plaintext file or a coll 
object, or better yet, use preset_hub/node system?


Best,

Ico


On 12/4/2016 2:38 PM, Jonathan Wilkes wrote:



> What about people parsing Pd files in Pd?  If they're searching for 
symbol "foo", are they going to have to deal with the edge case of 
symbol "foo\v"?


Ivica,
Just to give an example-- suppose someone is using a patch to store 
configuration data for their project.  They type the config data as 
comments in the
patch, much like [pd META].  Then they parse their patch from within 
Pd, using [textfile], or [text] or whatever.


Now, if they decide to insert some newlines into the comments to make 
their config prettier, as far as I understand this ends up appending 
an invisible
'\v' character to the last atom of each line.  So the next time they 
read their config they will get corrupted data that's hard to debug 
because the

character doing the corruption is non-printable.

That's the only direct downside I can see.  But as a design pattern 
it's problematic-- there are other places in Pd where a dev tried to 
use an
"obscure" character as a placeholder for something else.  That 
approach usually ends up creating more bugs.


-Jonathan


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

Re: [PD] cyclone comment and cross platform (was Re: Purr Data rc1)

[Jonathan Wilkes via Pd-list]

> What about people parsing Pd files in Pd?  If they're searching for symbol 
> "foo", are they going to have to deal with the edge case of symbol "foo\v"?
Ivica,Just to give an example-- suppose someone is using a patch to store 
configuration data for their project.  They type the config data as comments in 
the 
patch, much like [pd META].  Then they parse their patch from within Pd, using 
[textfile], or [text] or whatever.

Now, if they decide to insert some newlines into the comments to make their 
config prettier, as far as I understand this ends up appending an invisible 
'\v' character to the last atom of each line.  So the next time they read their 
config they will get corrupted data that's hard to debug because the 
character doing the corruption is non-printable.
That's the only direct downside I can see.  But as a design pattern it's 
problematic-- there are other places in Pd where a dev tried to use an 
"obscure" character as a placeholder for something else.  That approach usually 
ends up creating more bugs.
-Jonathan
   ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] cyclone comment and cross platform (was Re: Purr Data rc1)

[Ivica Ico Bukvic]

This only pertains to comments and as such should not make any 
difference elsewhere (unless you want to live-code something by hacking 
comments :-). Also, Pd-L2Ork inherited from extended search in patch 
option that offers match full or a subset of a string which should cover 
all the cases.



On 12/4/2016 1:57 PM, Jonathan Wilkes via Pd-list wrote:




*From:* IOhannes m zmölnig 
*To:* pd-list@lists.iem.at
*Sent:* Sunday, December 4, 2016 1:48 PM
*Subject:* Re: [PD] cyclone comment and cross platform (was Re: Purr 
Data rc1)


On 12/04/2016 07:13 PM, Jonathan Wilkes via Pd-list wrote:

>>  If they're searching for symbol "foo", are they going to have to 
deal with the edge case of symbol "foo\v"?


> hmm, how does "foo" not match "foo\v"?

[11(
|
[makefilename %c]
|
[symbol foo$1(
|
[select foo]
|
[bng]

-Jonathan

> grdsa
> 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


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

[PD] Equal panning formulas

[jlistshit]

Please excuse this question not entirely being related to Pure Data.

If i feed values 0-1 from linear [hsl] into either

[expr sqrt(1-$f1); sqrt($f1)]

or

[expr cos(1.57 * $f1); sin(1.57 * $f1)]

i essentially get the same set of output values, but with different input 
values. Obviously 0.5 puts both formulas to output 0.707 on both sides, but 
only extremes or center position input values (0, 1, 0.5) output the same 
results. 
The square root function leads to locations more near to the center, the other 
one has a wider image. 

A. Which one is the correct one from an engineering view point, and where are 
special cases which might lead to using the other one instead?

One of those cases occurs to me, when i have a foreground signal with a wide 
stereo image, but want a stereo reverb generated from this to be yet stereo, 
but responding stronger in the center.

B. What if i want to favor the center even more, though without leaving the 
idea of equal power panning (ah ja, mix it with a mono signal…, but which of 
the two formulas will i have to use then???)

Thank you very much in advance.

jayrope
- - -
www.jayrope.com
www.aircushionfinish.com
www.ello.co/jayrope



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

Re: [PD] cyclone comment and cross platform (was Re: Purr Data rc1)

[IOhannes m zmölnig]

On 12/04/2016 07:57 PM, Jonathan Wilkes via Pd-list wrote:
> [11(|[makefilename %c]|[symbol foo$1(|[select foo]|[bng]

ah, i misread your question - i was thinking of regexes (parsing the
file outside of Pd)

Pd itself doesn't provide any ways to *search* for a string; the best
you can get is to iteratively match atoms which fails in this case.

gfmrdsa
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] cyclone comment and cross platform (was Re: Purr Data rc1)

[Jonathan Wilkes via Pd-list]

  From: IOhannes m zmölnig 
 To: pd-list@lists.iem.at 
 Sent: Sunday, December 4, 2016 1:48 PM
 Subject: Re: [PD] cyclone comment and cross platform (was Re: Purr Data rc1)
   
On 12/04/2016 07:13 PM, Jonathan Wilkes via Pd-list wrote:
>>  If they're searching for symbol "foo", are they going to have to deal with 
>>the edge case of symbol "foo\v"?
> hmm, how does "foo" not match "foo\v"?

[11(|[makefilename %c]|[symbol foo$1(|[select foo]|[bng]
-Jonathan

> grdsa
> 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] cyclone comment and cross platform (was Re: Purr Data rc1)

[IOhannes m zmölnig]

On 12/04/2016 07:13 PM, Jonathan Wilkes via Pd-list wrote:
>  If they're searching for symbol "foo", are they going to have to deal with 
> the edge case of symbol "foo\v"?

hmm, how does "foo" not match "foo\v"?

grdsa
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] cyclone comment and cross platform (was Re: Purr Data rc1)

[IOhannes m zmölnig]

On 12/04/2016 03:10 AM, Liam Goodacre wrote:
> Spaces work in labels in L2Ork because they are escaped with a backslash. But 
> this is creating an incompatibility with Vanilla, which then can't read the 
> object's properties.

are you sure?
my impression is, that Pd can parse any labels with backslash-escaped
spaces just fine (see attached patch with a canvas with a label with
spaces, which works nicely on my Pd-0.47-1 as packaged in Debian).

the only problem occurs when you try to save such patches.

mgfdsar
IOhannes
#N canvas 4 49 450 300 10;
#X obj 120 71 cnv 15 100 60 empty empty foo\ bar 20 12 0 14 -233017 -66577
0;


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] cyclone comment and cross platform (was Re: Purr Data rc1)

[Jonathan Wilkes via Pd-list]

> Another thing that pd-l2ork's comment does that makes it theoretically 
> incompatible with vanilla, it recognizes line breaks and saves them. It uses 
> ASCII 11 to save it into the .pd file which is vertical tab that is by and 
> large unused. While vanilla shows line breaks when creating an object, 
> cutting and pasting it, or saving, closing, and reopening the file shows that 
> they don't get saved. As a result a lot of patches sidestep this by using 
> multiple comments, which is hard to maintain, particularly when it comes to 
> writing documentation.

 
  > Both improvements pd-l2ork uses could be easily ported back to vanilla as I 
cannot think of a scenario where it could potentially cause a breakage in 
backwards compatibility.
  
What about people parsing Pd files in Pd?  If they're searching for symbol 
"foo", are they going to have to deal with the edge case of symbol "foo\v"?

  > Best, 
  > Ico
  
 On 12/3/2016 9:10 PM, Liam Goodacre wrote:
  
 
#yiv8549058902 #yiv8549058902 -- P 
{margin-top:0;margin-bottom:0;}#yiv8549058902  Spaces work in labels in L2Ork 
because they are escaped with a backslash. But this is creating an 
incompatibility with Vanilla, which then can't read the object's properties.
  
 If you want a way to get larger, nicer text into a PD file than allowed with 
the ctrl+5 comment, the best way might be to use ASCII 255, the non breaking 
space (" "), which looks like a space but is read like a regular character. 
It's a bit of a pain to copy it between every word, but it works nicely across 
platforms once it's in place. A faster option for editing might be to let 
Vanilla replace spaces with underscores and then edit them in the .pd file with 
a text editor.
  
   From: Pd-list  on behalf of Jonathan Wilkes 
via Pd-list 
 Sent: 04 December 2016 01:27
 To: Alexandre Torres Porres
 Cc: Pd-List
 Subject: Re: [PD] cyclone comment and cross platform (was Re: Purr Data rc1)   
   Why not just use the built-in  comment?
  
 
   From: Alexandre Torres Porres 
 To: Jonathan Wilkes  
 Cc: Pd-List 
 Sent: Friday, December 2, 2016 1:10 PM
 Subject: Re: [PD] cyclone comment and cross platform (was Re: Purr Data rc1)
  
   Hi, I see Purr Data has this feature where it accepts spaces in lables such 
as in canvases... this is awesome, and mostly why I use cyclone/comment 
  I can see we could depart from how you can lable stuff in Purr Data to make a 
new working cross platform version of  cyclone/comment that is still backwards 
compatible. 
  cheers   
 2016-11-29 2:28 GMT-02:00 Alexandre Torres Porres :
 
  one question, how does canvas and other fonts for labels work in cross 
platforms?  
  why not use that for comment... for now, all cyclone/comment is can be 
thought of just being a  fancy label perhaps... 
  I did use it a lot in my new help files that I'm working on, but only cause 
it'd be too much  work to use canvas and labels, as it'd imply a canvas for 
each word as it doesn't take spaces (is only a symbol) 
  I was even thinking of ditching it when, it stopped working on vanilla 0.47 - 
yeah, that's  another thing, a fix needs to be made to vanilla for old versions 
of comment (0.2 and below to work) - but then I realized it could be really 
useful. I was also hoping  to add properties windows to make it more 
convenient. 
  anyway, the question is, why labels and stuff simply work? 
  cheers
 
  
 2016-11-28 21:45 GMT-02:00 Jonathan Wilkes  :
 
     
 

Another reason for putting it  off is that I still haven't figured 
out a sane approach 
   to handling arbitrary  fonts in a diagram where everything is  absolutely 
positioned.  
   In fact I only have a  minimally-workable approach to handling a  single, 
mono- 
   spaced font across  platforms.  For example, there was a  change somewhere 
in 
   the Gnu/Linux font-stack  (relatively) recently that renders fonts  (or at 
least 
   DejaVu Sans Mono)  noticeably wider than before.  So Windows, OSX, and 
   old Gnu/Linux would render a  particular line of text sized at  "12px" 
within less 
   than a single pixel of each  other.  The new Gnu/Linux font stack  (seen in 
Ubuntu 
   16.04 and some recent Arch)  rendered the same text about 7 pixels  wider.  
   Worse, the newer  Gnu/Linux font stack quantizes the  "px" sizes such that 
the  
   next smallest size is  noticeably smaller.  So in Ubuntu 16.04 I have  to 
compromise 
   by keeping the object box the  same size and having some extra padding at 
the 
   end-- otherwise  users of that OS could end up tightly  spacing their object 
chains  
   in ways that cause overlaps  on the other platforms. 
  So... I'd like to get a handle  on that mess first, then handling  arbitrary 
font 
   families-- as in  cyclone/comment-- will hopefully be easier and  less prone 
   to bugs.   
 
  

Re: [PD] cyclone comment and cross platform (was Re: Purr Data rc1)

[Ivica Ico Bukvic]

Another thing that pd-l2ork's comment does that makes it theoretically 
incompatible with vanilla, it recognizes line breaks and saves them. It 
uses ASCII 11 to save it into the .pd file which is vertical tab that is 
by and large unused. While vanilla shows line breaks when creating an 
object, cutting and pasting it, or saving, closing, and reopening the 
file shows that they don't get saved. As a result a lot of patches 
sidestep this by using multiple comments, which is hard to maintain, 
particularly when it comes to writing documentation.



Both improvements pd-l2ork uses could be easily ported back to vanilla 
as I cannot think of a scenario where it could potentially cause a 
breakage in backwards compatibility.



Best,


Ico


On 12/3/2016 9:10 PM, Liam Goodacre wrote:


Spaces work in labels in L2Ork because they are escaped with a 
backslash. But this is creating an incompatibility with Vanilla, which 
then can't read the object's properties.



If you want a way to get larger, nicer text into a PD file than 
allowed with the ctrl+5 comment, the best way might be to use ASCII 
255, the non breaking space (" "), which looks like a space but is 
read like a regular character. It's a bit of a pain to copy it between 
every word, but it works nicely across platforms once it's in place. A 
faster option for editing might be to let Vanilla replace spaces with 
underscores and then edit them in the .pd file with a text editor.




*From:* Pd-list  on behalf of Jonathan 
Wilkes via Pd-list 

*Sent:* 04 December 2016 01:27
*To:* Alexandre Torres Porres
*Cc:* Pd-List
*Subject:* Re: [PD] cyclone comment and cross platform (was Re: Purr 
Data rc1)

Why not just use the built-in  comment?



*From:* Alexandre Torres Porres 
*To:* Jonathan Wilkes 
*Cc:* Pd-List 
*Sent:* Friday, December 2, 2016 1:10 PM
*Subject:* Re: [PD] cyclone comment and cross platform (was Re: Purr 
Data rc1)


Hi, I see Purr Data has this feature where it accepts spaces in lables 
such as in canvases... this is awesome, and mostly why I use 
cyclone/comment


I can see we could depart from how you can lable stuff in Purr Data to 
make a new working cross platform version of cyclone/comment that is 
still backwards compatible.


cheers

2016-11-29 2:28 GMT-02:00 Alexandre Torres Porres >:


one question, how does canvas and other fonts for labels work in
cross platforms?

why not use that for comment... for now, all cyclone/comment is
can be thought of just being a fancy label perhaps...

I did use it a lot in my new help files that I'm working on, but
only cause it'd be too much work to use canvas and labels, as it'd
imply a canvas for each word as it doesn't take spaces (is only a
symbol)

I was even thinking of ditching it when, it stopped working on
vanilla 0.47 - yeah, that's another thing, a fix needs to be made
to vanilla for old versions of comment (0.2 and below to work) -
but then I realized it could be really useful. I was also hoping
to add properties windows to make it more convenient.

anyway, the question is, why labels and stuff simply work?

cheers


2016-11-28 21:45 GMT-02:00 Jonathan Wilkes >:



Another reason for putting it off is that I still haven't
figured out a sane approach
to handling arbitrary fonts in a diagram where everything
is absolutely positioned.
In fact I only have a minimally-workable approach to
handling a single, mono-
spaced font across platforms. For example, there was a
change somewhere in
the Gnu/Linux font-stack (relatively) recently that
renders fonts (or at least
DejaVu Sans Mono) noticeably wider than before.  So
Windows, OSX, and
old Gnu/Linux would render a particular line of text sized
at "12px" within less
than a single pixel of each other.  The new Gnu/Linux font
stack (seen in Ubuntu
16.04 and some recent Arch) rendered the same text about 7
pixels wider.

Worse, the newer Gnu/Linux font stack quantizes the "px"
sizes such that the
next smallest size is noticeably smaller.  So in Ubuntu
16.04 I have to compromise
by keeping the object box the same size and having some
extra padding at the
end-- otherwise users of that OS could end up tightly
spacing their object chains
in ways that cause overlaps on the other platforms.

So... I'd like to get a