Re: [PD] recursive controls problem

[Jonathan Wilkes]

I took a stab at it.

The main item here is the [set $1( message.  That allows you to update the 
display/state of the slider without outputting a value.

The [trigger a a] isn't needed for the patch to run correctly, but it makes it 
easier to see the connection that feeds back up the chain.

-Jonathan

On Friday, May 9, 2014 1:33 AM, plutek infinity  wrote:
 
greetings!

i'm sure this is a simple problem, but i can't seem to come up with the 
solution...

i'm trying to control one numerical value in a few ways:

1. have a bang to set an initial value
2. have a slider for mouse control
3. use keyboard keys to increment and decrement

the attached patch all works, except i ALSO want the slider position to 
pick up the current value, as changed by any of the other methods.

the problem is, of course, that if i connect the expr result back up to 
the slider input, i get a loop with "stack overflow" errors.

i'd be most grateful for any pointers you can offer... thanks much!

cheers!
.pltk.


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

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

[PD] more sprites!

[Jonathan Wilkes]

Hi list,
    Here's another data structure sprite example:
http://www.jonathanwilkes.net/sprite.webm

I changed the object name and interface a little bit-- now sprites can have 
affine transformations.  It's neat to use the "transform" method to see how few 
objects it takes to animate the sprite across the screen.

Under the hood, the transform method should also be more efficient-- instead of 
vis'ing and unvis'ing the scalar, it just sends updated attribute to the image.


Does anyone know if there's a standard sprite sheet format?  Some sprite sheets 
divide up the sections into perfectly equal parts-- others look like they just 
spread them out arbitrarily through a png or gif.  Atm I just take a directory 
as an arg and slurp up an image sequence.  (And use imagemagick to split up the 
sprite sheet.)

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

Re: [PD] Music notation in pure data

[Jonathan Wilkes]

On 04/29/2014 10:44 PM, Jaime E Oliver wrote:

I guess one of the nicest things about what you're showing is to do 
manipulations ala PWGL or open music. I'm interested in being able to make 
arbitrarily complex and long scores, and be able to export these as lilypond 
scores that can be edited and printed for someone else to play…


I see.  In that case I suppose you want to try to provide as much 
score-related data as you can for the converter to minimize your editing 
work.


-Jonathan



best,

J



On Apr 29, 2014, at 6:54 PM, Jonathan Wilkes  wrote:


On 04/29/2014 05:28 PM, Jaime E Oliver wrote:

Hi Jonathan,

This is excellent work!

I wonder in what direction are you taking this…

As far as notation inside Pd patches-- just the demo.  But I do remember Ed 
saying he'd initially investigated using data structures for his project.  If 
someone wants to build some higher level tools utilizing these new features of 
data structure, I'm happy to fix bugs and make any improvements that would be 
necessary.

But higher level tools are tricky-- their design depends on what you want to do 
with the notation.

As far as the data structures, in the next release I think I'll have the basic 
API the way I want it.  At some point I'd like to investigate drawing xlets on 
scalars that forward messages to the parent [struct]-- that would hide the 
complexity of [pointer] and friends in most cases.

Finally, I'd like to find a straightforward way to load canvases with [struct] 
definitions as libraries.  At that point people will be able to build GUI 
objects directly in Pd.

-Jonathan


best,

J


On Apr 29, 2014, at 1:20 PM, Jonathan Wilkes  wrote:


On 04/28/2014 11:21 PM, Max wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2014? 04? 29? 09:07, Jonathan Wilkes wrote:

I think somebody had one using Gem and dynamic patching.

that someone is Ed Kelly
http://www.uni-weimar.de/medien/wiki/PDCON:Conference/Gemnotes:_A_Realtime_music_notation_system_for_pure_data

Thanks.

Here's a demo of a simple Lilypond score imported into Pd-l2ork:
https://jwilkes.nfshost.com/notes.webm

Benefits of data structures:
* no dynamic patching needed
* can display the music on a normal canvas
* 2d API

Drawback:
* if you create a new scalar, the drawing instructions have to be sent to the 
gui.  (Even worse, ds-arrays have to redraw the entire array atm.)  But one 
could probably just instantiate a bunch of scalars and vis them as needed.

-Jonathan


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlNfGsEACgkQ3EB7kzgMM6KDSwCbBRP53mn0kDf5UAy6sm9iU487
xMQAnjtBN571+jVjRLSp0fN1rubo/a4G
=kUcj
-END PGP SIGNATURE-

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







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

Re: [PD] Music notation in pure data

[Jonathan Wilkes]

On 04/29/2014 05:28 PM, Jaime E Oliver wrote:

Hi Jonathan,

This is excellent work!

I wonder in what direction are you taking this…


As far as notation inside Pd patches-- just the demo.  But I do remember 
Ed saying he'd initially investigated using data structures for his 
project.  If someone wants to build some higher level tools utilizing 
these new features of data structure, I'm happy to fix bugs and make any 
improvements that would be necessary.


But higher level tools are tricky-- their design depends on what you 
want to do with the notation.


As far as the data structures, in the next release I think I'll have the 
basic API the way I want it.  At some point I'd like to investigate 
drawing xlets on scalars that forward messages to the parent [struct]-- 
that would hide the complexity of [pointer] and friends in most cases.


Finally, I'd like to find a straightforward way to load canvases with 
[struct] definitions as libraries.  At that point people will be able to 
build GUI objects directly in Pd.


-Jonathan



best,

J


On Apr 29, 2014, at 1:20 PM, Jonathan Wilkes  wrote:


On 04/28/2014 11:21 PM, Max wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2014? 04? 29? 09:07, Jonathan Wilkes wrote:

I think somebody had one using Gem and dynamic patching.

that someone is Ed Kelly
http://www.uni-weimar.de/medien/wiki/PDCON:Conference/Gemnotes:_A_Realtime_music_notation_system_for_pure_data

Thanks.

Here's a demo of a simple Lilypond score imported into Pd-l2ork:
https://jwilkes.nfshost.com/notes.webm

Benefits of data structures:
* no dynamic patching needed
* can display the music on a normal canvas
* 2d API

Drawback:
* if you create a new scalar, the drawing instructions have to be sent to the 
gui.  (Even worse, ds-arrays have to redraw the entire array atm.)  But one 
could probably just instantiate a bunch of scalars and vis them as needed.

-Jonathan



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlNfGsEACgkQ3EB7kzgMM6KDSwCbBRP53mn0kDf5UAy6sm9iU487
xMQAnjtBN571+jVjRLSp0fN1rubo/a4G
=kUcj
-END PGP SIGNATURE-


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






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

Re: [PD] Music notation in pure data

[Jonathan Wilkes]

On 04/28/2014 11:21 PM, Max wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2014? 04? 29? 09:07, Jonathan Wilkes wrote:

I think somebody had one using Gem and dynamic patching.

that someone is Ed Kelly
http://www.uni-weimar.de/medien/wiki/PDCON:Conference/Gemnotes:_A_Realtime_music_notation_system_for_pure_data


Thanks.

Here's a demo of a simple Lilypond score imported into Pd-l2ork:
https://jwilkes.nfshost.com/notes.webm

Benefits of data structures:
* no dynamic patching needed
* can display the music on a normal canvas
* 2d API

Drawback:
* if you create a new scalar, the drawing instructions have to be sent 
to the gui.  (Even worse, ds-arrays have to redraw the entire array 
atm.)  But one could probably just instantiate a bunch of scalars and 
vis them as needed.


-Jonathan




-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlNfGsEACgkQ3EB7kzgMM6KDSwCbBRP53mn0kDf5UAy6sm9iU487
xMQAnjtBN571+jVjRLSp0fN1rubo/a4G
=kUcj
-END PGP SIGNATURE-



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

Re: [PD] Music notation in pure data

[Jonathan Wilkes]

I think somebody had one using Gem and dynamic patching.

I've got a demo using svg-style drawing instructions in Pd-l2ork.  I'm almost 
finished working on nested svg groups-- at that point one should be able to 
output a page of Lilypond notation to svg and write an importer to convert to a 
Pd patch.

-Jonathan


On Monday, April 28, 2014 5:36 PM, "Pagano, Patrick" 
 wrote:
 
 
Is there a working music notator in PD?
 
pp
 
Patrick Pagano, B.S, M.F.A
Assistant in Digital Arts and Science
Digital Media Projection and Audio Design
Digital Worlds Institute 
University of Florida, USA
(352)294-2070
 
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] make first inlet a proxy inlet

[Jonathan Wilkes]

I think I answered my own question.  It looks like I can use CLASS_NOINLET, 
then create an inlet explicitly inside the *_new function for my classes.

On Monday, April 21, 2014 4:49 PM, Jonathan Wilkes  wrote:
 
Let's say I have foo_class that creates object [foo] and bar_class which 
creates object [bar].

I want the inlet of both to forward incoming messages to an object of type 
blah_class which serves as a proxy inlet.  (The struct of foo and bar would 
store a pointer to it and control creation and freeing of it.)

Is there a way to specify this inside foo_new and bar_new, or is the easiest 
way to just use a class_addanything and forward messages that way?


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

[PD] make first inlet a proxy inlet

[Jonathan Wilkes]

Let's say I have foo_class that creates object [foo] and bar_class which 
creates object [bar].

I want the inlet of both to forward incoming messages to an object of type 
blah_class which serves as a proxy inlet.  (The struct of foo and bar would 
store a pointer to it and control creation and freeing of it.)

Is there a way to specify this inside foo_new and bar_new, or is the easiest 
way to just use a class_addanything and forward messages that way?


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

Re: [PD] Error: Stack stack

[Jonathan Wilkes]

On 04/17/2014 03:49 AM, IOhannes m zmölnig wrote:

On 04/16/2014 06:39 PM, Jonathan Wilkes wrote:

you can locate many errors (though not all),

for he tech savy: you can locate all error messages that use
"pd_error()" or the not-so-new-but-still-newish "logpost()" to emit a
message.


by ctrl-clicking on the

error-message in the Pd-console,

When was that added,

afar, 0.43


and where is it documented?

src/CHANGELOG.txt?


Nope.



then there is [1], which is release announcement of Pd-extended but
really lists a lot of features also found in Pd-vanilla.

and every now and then it is mentioned on the list :-)


Discoverability trick: if the word "error:" is a hyperlink, most users 
will know that they can interact with that error message. Since clicking 
a hyperlink is standard behavior in a modern UI, there wouldn't be a 
(pressing) need to document the behavior.


In addition, a blue, underlined hyperlink fits perfectly with Pd's 1990s 
motif aesthetic.


-Jonathan



gfamse
IOhannes



[1] http://lists.puredata.info/pipermail/pd-list/2013-01/100666.html



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


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

Re: [PD] Error: Stack stack

[Jonathan Wilkes]

On 04/16/2014 11:16 AM, IOhannes m zmölnig wrote:

On 04/16/2014 02:33 PM, Cyrille Henry wrote:

the 1st thing to do in order to correct the problem is to locate it.

+1.

you can locate many errors (though not all), by ctrl-clicking on the
error-message in the Pd-console,


When was that added, and where is it documented?

-Jonathan


  which should highlight the object that
sent out the error-message.
in the case of a stack-overflow this will be any one of the objects in
the loop, but at least it gives you a starting point.

gfrdsa
IOhannes



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


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

Re: [PD] Keeping Number box's

[Jonathan Wilkes]

On 04/14/2014 02:03 PM, Phil Stone wrote:
Or use the "Number2" number box, and set its "init" attribute in 
properties. It will then init itself with the last value that was in 
the box at the time the parent patch was saved.


I try to avoid the iemgui "init" method because it isn't represented in 
the Pd diagram.


I'd rather do this:

[loadbang]

[42(
|
[numbox]

Then you can see if you made a mistake.  For example, I forgot to 
connect [loadbang] to [42(.  I can quickly scan all other places where I 
use [loadbang] to see if I made a similar error.


But if you use the "init" method, you must right-click and choose 
"Properties" on every single numbox to do error checking.  The time 
wasted isn't worth whatever it is you think you save by using "init".


Digression-- consider a Properties dialog with the following button:
[don't fire nukes]

Do you press it or not?

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

Re: [PD] keeping Pd DSP alive

[Jonathan Wilkes]

There isn't a way to poll the DSP state in Pd Vanilla.

-Jonathan

On Saturday, April 12, 2014 8:47 PM, Chris Clepper  wrote:
 
[pdinfo] is not part of vanilla.  I can't (nor want to) use extended for this 
project.

On Saturday, April 12, 2014, Jonathan Wilkes  wrote:

On 04/12/2014 04:27 PM, Chris Clepper wrote:
>
>Hi list 
>>
>>
>>I'm wondering if there are any recommended ways to ensure DSP keeps running 
>>for long periods like permanent installations.  I get 'audio I/O stuck' 
>>popping up every few days, which is not bad, but ideally audio should stay 
>>running indefinitely.
>>
>>
>>I can send a [metro 1000] to [;pd DSP 1( to keep audio going, but is there 
>>any long term issue with doing that?  Will it reliably restart audio after Pd 
>>closes it?
>>
>>
>>Also, the internal message [;pd audiostate( only returns data to the console. 
>> Perhaps there is a way to poll Pd for the internal DSP state and restart it 
>>if it dies?
>In Pd-l2ork:
>[dsp-status(
>|
>[pdinfo]
>
>-Jonathan
>
>
>
>>
>>Thanks!
>>
>>
>>
>>
>>___ Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list 
>___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] keeping Pd DSP alive

[Jonathan Wilkes]

On 04/12/2014 04:27 PM, Chris Clepper wrote:

Hi list

I'm wondering if there are any recommended ways to ensure DSP keeps 
running for long periods like permanent installations.  I get 'audio 
I/O stuck' popping up every few days, which is not bad, but ideally 
audio should stay running indefinitely.


I can send a [metro 1000] to [;pd DSP 1( to keep audio going, but is 
there any long term issue with doing that?  Will it reliably restart 
audio after Pd closes it?


Also, the internal message [;pd audiostate( only returns data to the 
console.  Perhaps there is a way to poll Pd for the internal DSP state 
and restart it if it dies?


In Pd-l2ork:
[dsp-status(
|
[pdinfo]

-Jonathan



Thanks!



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


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

[PD] Pd-l2ork release

[Jonathan Wilkes]

There's a new Pd-l2ork release:
http://l2ork.music.vt.edu/main/?page_id=56


Here's my vague recollection of what's changed:
* New preferences dialog that includes GUI settings, audio, and MIDI settings
* GUI presets (canvas bg, xlets, Pd window, search window, etc.)
* New "Put" menu array dialog with canvas and array properties in the same 
dialog
* Color choices for array trace
* Bar-graph array style
* Ability to create scalars inside an object box
* New [draw] drawing command for scalars: adds svg shapes rect, circle, 
ellipse, line, polyline, polygon, and path. (No text yet)
* Affine transformations, opacity, stroke, etc. messages for new draw commands
* New tutorials and demos for [draw] object
* New image and sprite draw commands (alpha)
* Improved search-plugin

There are a lot more changes that Ivica made-- I'll let him comment on those.

Best,
Jonathan___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Using GEM

[Jonathan Wilkes]

Do you mean something like the attached abstraction?  It turns your patches in 
a particular directory into a slideshow.

It uses an object called [canvasinfo] which is only available in Pd-l2ork.  If 
you don't use Pd-l2ork you can replace it with [iemguts/canvasname] (and remove 
the message box above it), but unfortunately [canvasname] in the last release 
of pd-extended had a bug that causes it not to work correctly in this case.

-Jonathan

On Tuesday, April 8, 2014 10:44 AM, Jack  wrote:
 
Le 08/04/2014 16:20, kate sweeney a écrit :
> Hello,
>
> I am currently doing my final year tech project in University. I am creating 
> a graphic design + music project using GEM in Pure Data. I was wondering, is 
> there a way to trigger certain patches, one after the other? For example, one 
> patch creates moving particles, and the next creates 3d spheres. Is there a 
> way to trigger these one after the other, using a bang etc? 
>
> Thank you. 
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list

Hello,

If you have you scenes (moving particles, 3d spheres, etc.) in the same
patch. The simplest is to send 0 or 1 to [gemhead] to render a scene.
One [gemhead] per scene.
With this method, you can put each scene in a subpatch ([pd
moving_particles], [pd 3d_spheres], etc.) and have a [receive ...]
arriving on the [gemhead].
Then, somewhere in your main patch, you put a radio button and test the
value return to activate a scene with [send ...].
++

Jack




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

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

Re: [PD] [qlist] and locality

[Jonathan Wilkes]

On 04/03/2014 07:13 PM, Roman Haefeli wrote:

[...]


Thanks for your remarks. You probably caught me in the act of feeling
comfortable in an actually not so comfortable situation. It's true that
people get accustomed to the environment they grow up in. I've never
challenged myself into thinking how things could be different as I found
ways to cover my needs with the clunky locality of $0.

Not yet fully seeing the impact, you convinced me that a more 'true'
locality would probably make some things easier.

And that is certainly not everything where Pd is clunky. I still find
myself using dynamic patching for problems I don't know how to solve
otherwise and that is not even an officially supported feature with a
definitely clunky interface.


Do you have any examples of such problems?  I'd be curious to see...

-Jonathan



Roman
  



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





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

Re: [PD] [qlist] and locality

[Jonathan Wilkes]

On 04/03/2014 06:33 PM, Alexandre Torres Porres wrote:
Hi Jonathan, I like it too, and the pedagogical concern is what gets 
me the most. I find new users to be reluctant to the clunkiness.


Had never heard of the Nova system, is it available somewhere? Seems 
it's not built on the core of Pd anyway, right?


No, it was abandoned.  I believe Tim develops something for 
Supercollider called "Supernova" which allows users to take advantage of 
parallelism when doing DSP.


[preset_hub] is in Pd-l2ork.

-Jonathan



thanks


2014-04-03 19:03 GMT-03:00 Jonathan Wilkes <mailto:jancs...@yahoo.com>>:


On 04/03/2014 03:13 PM, Alexandre Torres Porres wrote:

thanks for explaining it all

> imagine trying to design something like that
> which is also backwards compatible with the
> crude namespacing tools that already exist in Pd.
>  It's not possible

ok, here's where I'm a bit confuse. You're not saying it'd be
impossible to make messages inherit the $0 value, are you?


I don't know how difficult such a change is.  I assume something
in Pd's parser would need to be changed.  I can't remember if the
code responsible for parsing a msg box message even knows where
the message got sent from-- seems ike it doesn't since I can't
"find last error" on msg-box parsing errors (like an out-of-range
dollarsign variable).

What I'm saying is that even with a canvas $0 inside message boxes
Pd's scope system is still way too clunky. You still don't get
straightforward subpatch-locality, nor nested-abstraction
locality.  I think Tim Blechmann's Nova system did both, and
Ivica's [preset_hub] and [preset_node] get the latter (though I
don't think it does global scope).  Both work perfectly fine with
no $0 at all.  The pedagogical benefit is enormous-- new users can
get the scope they want without having to learn or think about
what a dollarsign variable is, or how string concatenation works. 
In the case of [preset_hub], just creating the object sets the
scope boundary almost certainly to what the user wants it to be. 
I like that.


-Jonathan




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

Re: [PD] [qlist] and locality

[Jonathan Wilkes]

On 04/03/2014 05:42 PM, Roman Haefeli wrote:

On Don, 2014-04-03 at 17:33 -0400, Jonathan Wilkes wrote:

So yes, it's rather extreme of me to advise users to just use global
symbols and switch languages when they run into problems.  But I think
there's an assumption on this list that most users know enough about
other programming languages to judge for themselves the level of
expressiveness in Pd.  I don't think that's true, and I think it's
important to remind people just how clunky Pd is in these respects
compared to other modern languages.

Clunky or not, Pd is the language I feel the most expressive with. YMMV.


Sorry, I'm not using the best terminology here.  I'm talking about the 
practical expressivity of the language.


For just one example-- let's say you wanted to make a polyphonic patch 
with 30 oscillators, and send them messages to set initial frequency and 
amplitude.  Let's use "Old-school Pd" which doesn't have abstractions.  
You make a subpatch, get it the way you want it, copy it, then paste it 
29 times.  Now when you need to make changes to the subpatch, you need 
to delete the other 29, copy the one you changed and paste it 29 times.  
That sucks.


Now let's look at "New-school Pd" which has abstractions.  In this case 
you get your abstraction the way you want it, instantiate it on a 
canvas, copy it, and paste it 29 times.  Now when you want to make a 
change to the abstraction, you click "Save" and Pd automatically pushes 
your changes to all instances of your abstraction.  You don't have to 
copy/paste everything again.  That's very simple, but it's one of the 
ways abstractions can make Pd more expressive.


So you can express yourself by programming in either version of the 
language.  But the "New-school" version makes it easier to do that. That 
may be clearer with the example of abstractions-- which you no doubt use 
all the time-- than with examples of scope that don't rely on $0.  But 
that's why I refer to other modern languages which don't suffer from 
that roadblock.


-Jonathan



Roman


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




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

Re: [PD] [qlist] and locality

[Jonathan Wilkes]

On 04/03/2014 03:13 PM, Alexandre Torres Porres wrote:

thanks for explaining it all

> imagine trying to design something like that
> which is also backwards compatible with the
> crude namespacing tools that already exist in Pd.
>  It's not possible

ok, here's where I'm a bit confuse. You're not saying it'd be 
impossible to make messages inherit the $0 value, are you?


I don't know how difficult such a change is.  I assume something in Pd's 
parser would need to be changed.  I can't remember if the code 
responsible for parsing a msg box message even knows where the message 
got sent from-- seems ike it doesn't since I can't "find last error" on 
msg-box parsing errors (like an out-of-range dollarsign variable).


What I'm saying is that even with a canvas $0 inside message boxes Pd's 
scope system is still way too clunky.  You still don't get 
straightforward subpatch-locality, nor nested-abstraction locality. I 
think Tim Blechmann's Nova system did both, and Ivica's [preset_hub] and 
[preset_node] get the latter (though I don't think it does global 
scope).  Both work perfectly fine with no $0 at all. The pedagogical 
benefit is enormous-- new users can get the scope they want without 
having to learn or think about what a dollarsign variable is, or how 
string concatenation works.  In the case of [preset_hub], just creating 
the object sets the scope boundary almost certainly to what the user 
wants it to be.  I like that.


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

Re: [PD] [qlist] and locality

[Jonathan Wilkes]

On 04/03/2014 04:14 PM, Roman Haefeli wrote:

On Don, 2014-04-03 at 12:00 -0400, Jonathan Wilkes wrote:

* when you run into nameclashes, you know your project has outgrown Pd
and it's time to choose another language

That is a pretty bold statement.


It's meant as a shortcut to avoid wasting time.


  I never ever run into name clashes, no
matter how big the project was/is.

The no-name-clash dogma:

* Do not use global s/r-symbols (simple)


Except you have two points below which contradict this!

But I suppose you meant to write that one shouldn't use global 
s/r-symbols except for the two special cases below.  Even so, what you 
ignore is the entire learning curve that accompanies the dogma. The new 
user is presented with the perverse starting point that the simple, 
common case of global symbols should be used almost never and the 
cryptic, dollarsign-zero symbol names should be used almost always.


Because the user must rely on cryptic dollarsign symbols for locality, 
patching is more error-prone, and patches are harder to read.  Every 
message box is accompanied by the user's choice of extra patch cruft to 
feed $0 into it.  Maybe it's [f $0], [list prepend $0], an abstraction, 
or something else.  That yet one more little detail to check when things 
go wrong, and it's there because the user is forced to type something 
extra to get patch locality, which is most often what the user needs.


So yes, it's rather extreme of me to advise users to just use global 
symbols and switch languages when they run into problems.  But I think 
there's an assumption on this list that most users know enough about 
other programming languages to judge for themselves the level of 
expressiveness in Pd.  I don't think that's true, and I think it's 
important to remind people just how clunky Pd is in these respects 
compared to other modern languages.


-Jonathan



* Use global s/r-symbols for singletons (i.e. one server, many clients)

* Use global s/r-symbols in cases where the protocol is multinode-aware.
   (No matter how many instances of an abstraction using a global s/r-
   symbol are created, they will always be able to communicate with each
   other in the same way)

Roman
  




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



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

Re: [PD] [qlist] and locality

[Jonathan Wilkes]

For example, if you have two help patches open and each has an array inside it 
named "array1".  One of the help patches will work, and the other won't.  
That's because "Put" menu arrays assume you only have one array by that name.  
Pd will use the first one it finds (probably the first one you create) and the 
duplicate will be ignored.

In the case of arrays you'll get a warning, because you're not supposed to use 
the same name twice.  But with the send/receive classes (as well as many other 
objects that use pd_bind) you can have many s/r pairs sharing the same name.

So suppose you have [s loop] and [r loop] in a subpatch, and [s loop] and [r 
loop] in an unrelated subpatch.

Are those s/r pairs supposed to communicate with each other?  Or...
Did the author forget he/she already used the name "loop" for the first s/r 
pair and doesn't actually want the other s/r pair to communicate with the first?


If the answer to the second question is yes, then that's an example of a 
nameclash.  Pd doesn't give you a way to tell the difference.  Most programming 
languages have clear and sensible ways to avoid this.  There's even a Pd 
external to do it-- I think it's called [sendlocal] and [receivelocal]-- but 
its author erroneously thought that $0 deprecates those objects.

Pd gurus on the list can give you seemingly simple workarounds for these 
problems with scope and nameclashes, but as you the programmer accumulate them 
it gets more and more unwieldy.  Worse, it makes it difficult to read patches, 
as you must spend time decoding someone else's idiosyncratic use of 
[makefilename] or whatever they are doing to get Pd to do what is concise, 
consistent and robust in nearly every other modern programming language.

Finally-- and again-- these problems cannot be improved in Pd without breaking 
some backwards compatibility.  Just take the related issue of namespaces with 
external libraries-- it's hard enough to design and test something robust like 
Python's namespacing.  Now imagine trying to design something like that which 
is also backwards compatible with the crude namespacing tools that already 
exist in Pd.  It's not possible, and that means as long as people imagine Pd 
Vanilla as the "core" Pd $0 hackery is the only way to simulate scoping.

-Jonathan
On Thursday, April 3, 2014 12:35 PM, Alexandre Torres Porres  
wrote:
 
> * when you run into nameclashes, you know your project 
> has outgrown Pd and it's time to choose another language


what's a nameclash? (maybe I haven't  outgrown Pd yet)



2014-04-03 13:00 GMT-03:00 Jonathan Wilkes :

On 04/03/2014 04:00 AM, IOhannes m zmoelnig wrote:
>
>-BEGIN PGP SIGNED MESSAGE-
>>Hash: SHA256
>>
>>On 2014-04-03 03:05, Alexandre Torres Porres wrote:
>>
>>
>
[...]
>
>
>
>
>>btw: i would probably even recommend to use explicit *connections*
>>(rather than send/receive pairs) for anything local. then you never
>>have the problem of "[qlist] and locality" - very simple  and forces
>>you to think about your object interfaces.
>>
>
I would also recommend only using global receive-symbols when you have to use 
them.  That way:
>* your patches are more readable
>* no need to feed $0 to message boxes
>* when you run into nameclashes, you know your project has outgrown Pd and 
>it's time to choose another language
>
>-Jonathan
>
>
>
>
>>
>>
>>fgmasdr
>>IOhannes
>>-BEGIN PGP SIGNATURE-
>>Version: GnuPG v1
>>Comment: Using GnuPG with Icedove - http://www.enigmail.net/
>>
>>iQIcBAEBCAAGBQJTPRULAAoJELZQGcR/ejb4NioP/0Kyyz4MA+Tqq8890uEHGj9Z
>>FZHEo5z/idBj7Z+WmAHrEipkIW70pnVBB4bVzC8owgV66AQZBuEqXMeJcIpu3MXK
>>ULvsvxcFcoY9YH7hbJAF+mlDFvbh1CXcVbvEChZ8y5rz0XekSMf+//qUfJSlKTWX
>>GXjJzw8s42yfSpVJYBjEh6fBFzlk2foLRFPFXaR6Cbj+Y7aNEiW//+Vim3nOzleT
>>6azYe0leLabir72nnWIKGahnT2GXgWkgxu6L//nTgsBYOa1COUoKOh44wvBbMSoW
>>lbLduDY5drxJbyISGoZdsuailriv1xMGIkiSwTw4WSwVWBj2kv5MgoHC09ugqtLe
>>bVHrizcP09+VUz20y8IMnXrRRgj8AU8Z+9xzZIzf9PV3U15zSlRqwZSFIwMCuhYs
>>CeRqxtDFVsB/PARQoCys/B4QDjAszBPE2VC1xKSelBMjyGbvPyZA7uq/R199zLCy
>>WMp0uu0+Q6WKa/zIB+sphLlifnXjYYXJaCGZNOzign1EJLOnBvOY/4zgE3bHtx9r
>>FIlSFSMo6BrYjOEJvh/MxF90TawI/aCQ/MbEea0+finxJi2jp2PnMom+QbCvjfBa
>>zLh8hlNP0tLp21Jo1ydzu0/vYb9mEzMQtpEv9lqrde0INcEKL9TaswFGf5TXyM7h
>>JeTnSBV0Th0CjQER9Gik
>>=oC+u
>>-END PGP SIGNATURE-
>>
>>___
>>Pd-list@iem.at mailing list
>>UNSUBSCRIBE and account-management -> 
>>http://lists.puredata.info/listinfo/pd-list
>>
>
>___
>Pd-list@iem.at mailing list
>UNSUBSCRIBE and account-management -> 
>http://lists.puredata.info/listinfo/pd-list
>___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [qlist] and locality

[Jonathan Wilkes]

On 04/03/2014 04:00 AM, IOhannes m zmoelnig wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2014-04-03 03:05, Alexandre Torres Porres wrote:



[...]



btw: i would probably even recommend to use explicit *connections*
(rather than send/receive pairs) for anything local. then you never
have the problem of "[qlist] and locality" - very simple  and forces
you to think about your object interfaces.


I would also recommend only using global receive-symbols when you have 
to use them.  That way:

* your patches are more readable
* no need to feed $0 to message boxes
* when you run into nameclashes, you know your project has outgrown Pd 
and it's time to choose another language


-Jonathan





fgmasdr
IOhannes
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJTPRULAAoJELZQGcR/ejb4NioP/0Kyyz4MA+Tqq8890uEHGj9Z
FZHEo5z/idBj7Z+WmAHrEipkIW70pnVBB4bVzC8owgV66AQZBuEqXMeJcIpu3MXK
ULvsvxcFcoY9YH7hbJAF+mlDFvbh1CXcVbvEChZ8y5rz0XekSMf+//qUfJSlKTWX
GXjJzw8s42yfSpVJYBjEh6fBFzlk2foLRFPFXaR6Cbj+Y7aNEiW//+Vim3nOzleT
6azYe0leLabir72nnWIKGahnT2GXgWkgxu6L//nTgsBYOa1COUoKOh44wvBbMSoW
lbLduDY5drxJbyISGoZdsuailriv1xMGIkiSwTw4WSwVWBj2kv5MgoHC09ugqtLe
bVHrizcP09+VUz20y8IMnXrRRgj8AU8Z+9xzZIzf9PV3U15zSlRqwZSFIwMCuhYs
CeRqxtDFVsB/PARQoCys/B4QDjAszBPE2VC1xKSelBMjyGbvPyZA7uq/R199zLCy
WMp0uu0+Q6WKa/zIB+sphLlifnXjYYXJaCGZNOzign1EJLOnBvOY/4zgE3bHtx9r
FIlSFSMo6BrYjOEJvh/MxF90TawI/aCQ/MbEea0+finxJi2jp2PnMom+QbCvjfBa
zLh8hlNP0tLp21Jo1ydzu0/vYb9mEzMQtpEv9lqrde0INcEKL9TaswFGf5TXyM7h
JeTnSBV0Th0CjQER9Gik
=oC+u
-END PGP SIGNATURE-

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



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

Re: [PD] [qlist] and locality

[Jonathan Wilkes]

On 04/02/2014 03:08 AM, Roman Haefeli wrote:

On Tue, 2014-04-01 at 17:20 -0300, Alexandre Torres Porres wrote:

you might want to see the messages sent by [qlist]
the same as messages in msgboxes,
where you don't have $0-expansion either


Bummer. anyway, this brings me to a different topic then. Why is there
this lack of expansion in messages?

Message boxes _do_ expand dollar arguments.


I think I've raised this issue sometime ago. Sorry I don't remember
what the problem was, but I'd like to ask again if it's really really
hard to expand the functionality in messages, or if this could happen
sometime soon in Pd.

The difference is that dollar arguments in message boxes expand to the
incoming message while dollar arguments in object boxes expand to the
arguments given to the parent. $0 in object boxes is actually an
argument given implicitly by Pd to the parent (every instance of a Pd
file gets a separate one).
  

I believe there won't be any compatibility issues by expanding this
functionality. Old patches will still work and newer patches could be
simpler, right?

You're asking for inconsistency: You propose to have a mixture of dollar
arguments in message boxes, namely you want $0 to expand to an argument
of the parent and all other dollar arguments expand according to the
incoming message.


I think what the OP wants is some minimally-workable notion of scope wrt 
receive-symbols.  Because $0 doesn't deliver this, the next best thing 
is an inconsistent $0 that gets closer to minimally-workable scope.  It 
says something that so many people are willing to overlook the 
inconsistency to get behavior that doesn't cause them to pull their hair 
out.




While I also don't see how your proposal would break compatibility, I
think what I said above is the reasoning why things are how they are.


Tim Blechmann already addressed scope and implemented a solution in 
Nova.  There are certainly developers in the Pd community who could port 
that idea, or maybe even something better.  But free software devs have 
limited time, and they're smart, so they know if a now prominent 
Supercollider dev can't get such a needed improvement into Pd then they 
probably have 1000 better ways to spend their time.


-Jonathan


While I don't have a strong opinion on the subject matter, I suspect it
is not going to be changed soon (it was brought up a few times already,
iirc).


Roman
  






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





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

Re: [PD] Pd-L2Ork [ii]

[Jonathan Wilkes]

On 03/31/2014 12:25 PM, IOhannes m zmölnig wrote:

On 03/31/2014 05:09 PM, Jonathan Wilkes wrote:

a) click [loadbang] with the mouse to output a bang.  (This is how Max/MSP 
solves this problem, too.)
b) select all the objects to which you'd like to connect, then draw a 
connection from [bng] to one of them.  In Pd-l2ork this will make a connection 
from the outlet to all of the selected objects.

c) replace [loadbang] with [t b], then create a [bng] and a new
[loadbang] and connect both to that [t b].


Yeah, I forgot about that one.  It's a nice trick of "recycling" a wire 
which generalizes to other situations, too.


-Jonathan



this is still a lot more work that a), but a lot less than b) if you
don't have Pd-l2ork's patching features though it might be more readable.

fgmdsar
IOhannes



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


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

Re: [PD] Alternatives to arraycopy

[Jonathan Wilkes]

I used some simple data mining techniques to infer the following: you didn't 
actually test those objects in a patch before writing your response.

[ads based on this inference go here]

-Jonathan

On Monday, March 31, 2014 9:05 AM, Miller Puckette  wrote:
 
Just play it (tabplay~) into the other one (tabrecord~).  You can do this
at many times 'normal' speed if you want by putting it in a subpatch
with a high sample rate.

cheers
Miller

On Mon, Mar 31, 2014 at 08:58:22AM -0400, Johann Diedrick wrote:
> Hi Pd list-
> 
> I have a question about the object arraycopy. It works great, but I'm
> copying an array with 1323 points (5 minutes of audio at 44,100 hz) and
> it seems very slow. In particular, my patch seems to "lock" up for about
> 2-3 seconds when making the copy. The audio stops for those 2 seconds, and
> the UI seems to lock up. While this isn't a huge game changer for my
> purposes, I wish there was an alternative for this. Is there a better
> solution for making a copy on the fly for an array this big that is faster,
> doesn't lock up the patch or kill the audio for that time period? Maybe
> there is a threaded solution?
> 
> I'd love to hear any thoughts on this!
> 
> Thanks so much,
> 
> -Johann

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


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

Re: [PD] Pd-L2Ork [ii]

[Jonathan Wilkes]

I wouldn't use [init].  The same functionality is available using [loadbang] 
connected to a storage object ([float], [list], message box, etc.).  And 
[loadbang] is available in all versions of Pd, so your patch will be more 
portable.

The [init] object's args make patching _slightly_ easier.  The inlet makes it 
more expressive, but a subtle feature of [loadbang] is that it's easier to spot 
because it's always at the top of a chain.  Also "init" as class name is 
problematic-- [float 6] "inits" to 6, after all, but does not output a message 
upon initialising.  I suppose the idea is to be consistent with iemgui "init", 
which itself is obscure and requires the user to bring up a dialog window to 
understand how the patch works.  (Not to mention it clashes with [initbang], 
where "init" has a different meaning altogether.)

The only other potential advantage is that if you have [init] fanning out to 
several objects, you can test your patch by simply by connecting [bng] to the 
inlet of [init].  With [loadbang] you would have to create a [bng] and then 
connect it to every object that [loadbang] connects to.  But at least in 
Pd-l2ork you can either:

a) click [loadbang] with the mouse to output a bang.  (This is how Max/MSP 
solves this problem, too.)
b) select all the objects to which you'd like to connect, then draw a 
connection from [bng] to one of them.  In Pd-l2ork this will make a connection 
from the outlet to all of the selected objects.

-Jonathan

On Monday, March 31, 2014 10:23 AM, "pured...@11h11.com"  
wrote:
 
init_class = class_new(gensym("init"), (t_newmethod)init_new,
     (t_method)init_free, sizeof(t_init), 0, A_GIMME, 0);

   class_addcreator((t_newmethod)init_new, gensym("ii"), A_GIMME, 0);

Will continue to test Pd-L2Ork (I had some difference with pd-extended  
regarding -path (not all my abstractions were found)). Will report back.

BTW, I never used the PPA thing on LaunchPad, but it would be nice for  
installing / updating Pd-L2Ork.

à+

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

[PD] comments as one long symbol

[Jonathan Wilkes]

That way we could implement a simple translation system.

When Pd loads a patch it looks for a translation file in the local language 
that share the same base file name as the patch.  If there isn't a translation 
file then a comment would load as is.  If there is a translation file for the 
user's language then Pd searches the translation file for the comment and loads 
up the corresponding translated comment.

So why do comments as one long symbol help?  Because then a search is as simple 
looping through an array of atoms and doing:

if (gensym(buf) == gensym(translation_file_buf))

Fast and simple.  And you just need an extra entry in the ce_env struct to hold 
the name of the translation file for the user's locale.

I still don't know how gettext works, but I'm guessing we could set it up to 
pull out comments from a Pd file, then use that to generate the template for 
the help patch translations.

Comments?  Attacks?  Beers?

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

Re: [PD] pd source code style

[Jonathan Wilkes]

Great.

Thanks,
Jonathan



On Saturday, March 22, 2014 2:37 PM, Miller Puckette  wrote:
 
There aren't any tabs (so that it doesn't matter how you have set your
tab spacing to look at the code).

The code uses 4-space indentation.  (That shouldn't be affected by tab spacing).

cheers
Miller


On Sat, Mar 22, 2014 at 11:08:50AM -0700, Jonathan Wilkes wrote:
> In the changes.txt it says that indentation is four spaces?  Does that mean 
> that a click of the "tab" key is supposed to generate four consecutive 
> spaces?  I don't see any tab characters in the source (unless I'm searching 
> them wrong.)
> 
> Thanks,
> Jonathan

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

[PD] pd source code style

[Jonathan Wilkes]

In the changes.txt it says that indentation is four spaces?  Does that mean 
that a click of the "tab" key is supposed to generate four consecutive spaces?  
I don't see any tab characters in the source (unless I'm searching them wrong.)

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

Re: [PD] log function in slider

[Jonathan Wilkes]

No, the code I ported is from vslider_set and vslider_draw_update (might be 
different in Vanilla).

In vslider_bang, math is done to output the proper value.  Without looking at 
the code I would have guessed vslider_bang simply outputs a stored value like 
[float] does.  Then just do math to set the slider position or calculate a new 
stored value from mouse input.

-Jonathan




On Monday, March 17, 2014 1:21 AM, Alexandre Torres Porres  
wrote:
 
Hi Roman. This is turning out trickier than I thought. A friend explained the 
code to me and got to the following equation, with min/max values as 0.01 and 1 
respectively.

[expr 0.01 * exp((log(1 / 0.01) / 0.01) * $f1 * 0.01)]


For what I've checked, it seems to behave like your patch. But it doesn't do 
the trick I'm looking for yet. I sent a patch earlier, and I'm sending it back 
again.

The goal is to connect a linear slider to an [expr] (with this so called "log" 
function) and then to another linear slider. The idea then is that this second 
slider behaves as one that was set as being "log".

In the patch attached I was able to emulate it poorly with [pow 0.25], but that 
was before reaching the list. See that if I use this expr function from the 
code or your patch it presents quite a different behavior.

maybe it is some sort of inversion of this equation, not sure. Apparently this 
code converts the "log" function values to linear and I'm hoping to get the 
exact opposite. Got it?

Thanks for looking into this



2014-03-12 4:38 GMT-03:00 Roman Haefeli :

On Don, 2014-03-06 at 21:37 -0300, Alexandre Torres Porres wrote:
>> hi folks, out of curiosity, what's the exact log function used in the
>> slider? I'd like to emulate it.
>
>I am not sure, if this is what you want. It converts the incoming linear
>range between 0 and 1 to a logarithmic range specified by $1 and $2,
>respectively by the second and third inlet. They behave like the lower
>and upper bound specified in the [vslider]/[hslider] classes.
>
>https://raw.github.com/reduzent/netpd2-patches/master/abs/rh_scalelog.pd
>
>
>Roman
>
>
>
>
>
>___
>Pd-list@iem.at mailing list
>UNSUBSCRIBE and account-management -> 
>http://lists.puredata.info/listinfo/pd-list
>

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

Re: [PD] log function in slider

[Jonathan Wilkes]

On 03/17/2014 04:34 PM, Roman Haefeli wrote:

On Mon, 2014-03-17 at 02:21 -0300, Alexandre Torres Porres wrote:

Hi Roman. This is turning out trickier than I thought.

I think I understand now what you are trying to achieve (sorry, took me
a long time). But I don't really have a clue how to do it. The
abstraction I posted emulates the output of a logarithmic slider, but
you're looking for the function to feed a linear slider so that it
behaves as if it would be a logarithmic slider, right?
   
I'm interested to see, if someone comes up with a solution...


This is from Pd-l2ork, so the codebase might be slightly different.

Also, notice I've got hard-coded slider height = 128 in the algo.

Still don't understand why math is done in vslider_bang.

-Jonathan



Roman





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




#N canvas -9 19 513 614 10;
#X obj 16 319 cnv 15 202 227 empty empty empty 20 12 0 14 -233017 -66577
0;
#X obj 65 57 cnv 15 351 255 empty empty empty 20 12 0 14 -233017 -66577
0;
#X floatatom 148 27 5 0 0 0 f - -, f 5;
#X obj 217 162 log;
#X obj 217 120 f 1;
#X obj 217 141 / 0.01;
#X obj 217 183 /;
#X obj 276 131 f 128;
#X obj 276 152 - 1;
#X text 331 139 x_k;
#X obj 148 142 / 0.01;
#X obj 148 163 log;
#X obj 148 230 /;
#X obj 148 67 t a b b;
#X obj 148 251 * 100;
#X obj 148 272 + 0.4;
#X obj 148 293 int;
#X text 190 295 <- x_xval;
#X obj 148 374 t b a;
#X obj 148 395 f 2;
#X obj 148 416 + 127;
#X obj 148 437 -;
#X text 183 435 <- r;
#X obj 148 324 + 50;
#X obj 148 345 / 100;
#X obj 235 493 vsl 15 128 0 127 0 0 empty empty empty 0 -9 0 10 -262144
-1 -1 0 1;
#X msg 148 459 128 \$1;
#X obj 148 480 -;
#X obj 288 493 vsl 15 128 0.01 1 1 0 empty empty empty 0 -9 0 10 -262144
-1 -1 0 1;
#X text 68 58 vslider_set;
#X text 21 326 vslider_draw_update;
#X text 115 581 linear slider ->;
#X text 315 581 <- logarithmic slider;
#X connect 2 0 13 0;
#X connect 2 0 28 0;
#X connect 3 0 6 0;
#X connect 4 0 5 0;
#X connect 5 0 3 0;
#X connect 6 0 12 1;
#X connect 7 0 8 0;
#X connect 8 0 6 1;
#X connect 10 0 11 0;
#X connect 11 0 12 0;
#X connect 12 0 14 0;
#X connect 13 0 10 0;
#X connect 13 1 4 0;
#X connect 13 2 7 0;
#X connect 14 0 15 0;
#X connect 15 0 16 0;
#X connect 16 0 23 0;
#X connect 18 0 19 0;
#X connect 18 1 21 1;
#X connect 19 0 20 0;
#X connect 20 0 21 0;
#X connect 21 0 26 0;
#X connect 23 0 24 0;
#X connect 24 0 18 0;
#X connect 26 0 27 0;
#X connect 27 0 25 0;
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Tannhauser Pure Data compiler

[Jonathan Wilkes]

On 03/17/2014 01:53 PM, Joe White wrote:

Hey guys,

I'm working on this at the moment with Martin. It's basically a way of 
compiling a Pd patch to an optimised C library for embedding in 
devices or applications.


We're looking to release


Releasing the code?

-Jonathan


this very soon, we'll keep everyone posted when it happens.

Cheers,
Joe


On 17 March 2014 13:37, Ingo > wrote:


Yeah, I had found that but nothing else except that the "OWL", a
programmable effects pedal, can use Pd patches after compiling
them to C
with Tannhauser.



Von: pd-list-boun...@iem.at 
[mailto:pd-list-boun...@iem.at ] Im
Auftrag von
Pierre Massat
Gesendet: Montag, 17. März 2014 14:12
An: Simon Wise
Cc: pd-list
Betreff: Re: [PD] Tannhauser Pure Data compiler

Not much information on either page...
Pierre.

2014-03-17 14:06 GMT+01:00 Simon Wise mailto:simonzw...@gmail.com>>:
On 17/03/14 23:26, Ingo wrote:
I just found out about the "Tannhäuser Pure Data compiler".
Does anybody know who makes it or where to get this compiler?

Thanks!
Ingo

google took me here ...

https://www.hackerleague.org/hackathons/automatic-music-hackathon/hacks/tann
hauser-a-c-compiler-for-pure-data



perhaps Martin Roth is your man

https://www.hackerleague.org/users/mhroth


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



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




--
Follow me on Twitter @diplojocus


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


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

Re: [PD] log function in slider

[Jonathan Wilkes]

AFAICT vslider is saving something like a slider position, and your expression 
above (along with the code I posted) is for getting back the original value 
from it.  If you send it something between 0.01 and 1 you'll get a curve that's 
inverted from the one you're after.  If you send it a slider position-- 
something like another [expr] based on the code inside vslider_set-- you'll get 
back (roughly) the same value you input.

But I'm still stuck on why vslider_bang is doing any math at all.  Why should 
it be more complex than "if bang then output stored value"?  (Setting aside 
sending to receive symbols for the moment.)

-Jonathan




On Monday, March 17, 2014 1:21 AM, Alexandre Torres Porres  
wrote:
 
Hi Roman. This is turning out trickier than I thought. A friend explained the 
code to me and got to the following equation, with min/max values as 0.01 and 1 
respectively.

[expr 0.01 * exp((log(1 / 0.01) / 0.01) * $f1 * 0.01)]


For what I've checked, it seems to behave like your patch. But it doesn't do 
the trick I'm looking for yet. I sent a patch earlier, and I'm sending it back 
again.

The goal is to connect a linear slider to an [expr] (with this so called "log" 
function) and then to another linear slider. The idea then is that this second 
slider behaves as one that was set as being "log".

In the patch attached I was able to emulate it poorly with [pow 0.25], but that 
was before reaching the list. See that if I use this expr function from the 
code or your patch it presents quite a different behavior.

maybe it is some sort of inversion of this equation, not sure. Apparently this 
code converts the "log" function values to linear and I'm hoping to get the 
exact opposite. Got it?

Thanks for looking into this



2014-03-12 4:38 GMT-03:00 Roman Haefeli :

On Don, 2014-03-06 at 21:37 -0300, Alexandre Torres Porres wrote:
>> hi folks, out of curiosity, what's the exact log function used in the
>> slider? I'd like to emulate it.
>
>I am not sure, if this is what you want. It converts the incoming linear
>range between 0 and 1 to a logarithmic range specified by $1 and $2,
>respectively by the second and third inlet. They behave like the lower
>and upper bound specified in the [vslider]/[hslider] classes.
>
>https://raw.github.com/reduzent/netpd2-patches/master/abs/rh_scalelog.pd
>
>
>Roman
>
>
>
>
>
>___
>Pd-list@iem.at mailing list
>UNSUBSCRIBE and account-management -> 
>http://lists.puredata.info/listinfo/pd-list
>

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

Re: [PD] udoo board sound issues

[Jonathan Wilkes]

On 03/16/2014 05:33 AM, Simon Iten wrote:

[...]


Any digital instrument also has latencies. Basically it is a matter of playing 
the instrument you are using.


How are you measuring the latency?

-Jonathan




Simon

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

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





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

Re: [PD] using pd live (sans computer/laptop/raspberry pi)

[Jonathan Wilkes]

On 03/14/2014 03:44 PM, Dan Wilcox wrote:

Without a computer, no. Without a desktop or laptop computer, yes.


Well, maybe we could design and manufacture an enormous ASIC that runs 
libpd.


-Jonathan

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

Re: [PD] Data structures and click event

[Jonathan Wilkes]

On 03/07/2014 06:55 PM, Miller Puckette wrote:

I'll have to have a look and see what the ideas are... I don't
know anything yet.


Well there's the important stuff:
https://jwilkes.nfshost.com/mm.webm

And then the less important stuff, like being able to patch 15 out of 
the 28 demos shown here:

http://raphaeljs.com/

Essentially everything except the ones with gradients and text, but 
those features can be added later.


It's generally not as high level as Raphael-- for example I ported the 
Raphael code to subpatches for the easing demo, and I'm just using 
[line] to do the animation.  However, it would not be too hard on the Pd 
side to add an "animate" method.  In fact that'd be quite efficient as 
you'd only be sending a single message over the socket and letting the 
GUI take care of the details.


Also, I'm instantiating scalars inside object boxes.  Since the user can 
send messages to update shape attributes straight to the parent draw 
command, this means he/she can do an end-run around pointers for 
prototyping.  So essentially you have the ability to dynamically change 
visual attributes on the class level (i.e., the parentwidgetbehavior) 
and on the object level (for the specific scalar, as you can currently).


There are still lots of details to get right, like handling groups 
properly, but the basic stuff is there.


-Jonathan


   Anyhow I think there are a couple of things
that are higher priority:  getting editing to be more user-friendly,
and getting the IEM GUIs to behave better.  And I'm afraid I can
only write code at a fraction of the speed others can - so PD
vanilla will always seem years behind everything else.

cheers
Miller

On Sat, Mar 08, 2014 at 12:45:33AM +0100, João Pais wrote:



On 03/05/2014 05:24 AM, Pierre Massat wrote:

Dear list,

First of all i'd like to say that i'm very impressed by the
potential of data structures in Pd. I've always kind of ignored
this feature and it's a >>pity because it's really worth diving
into it.That being said I think that help and example patches
are far from sufficient for beginners, and if it wasn't for
Chris McCormick's s->>abstractions I would have been able to
really figure out how to use them (stuff like how to make an
entire polygon draggable, how to use >>GOP with proper scaling,
etc.).

It's not just the documentation, it's the interface.  Having to
walk linked-lists of graphically unlinked objects is bad.  Having
to use boilerplate to find the >head of a glist just to create a
scalar is bad.

I think Pd-l2ork is getting close to a release with my new data
structure stuff in it.  It's a first step at addressing some of
these issues.

and any prospects of that stuff making it into vanilla or pd-ext,
for the non-unix users out there?
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list





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

Re: [PD] log function in slider

[Jonathan Wilkes]

Wow, never mind-- it's a veritable Rube Goldberg machine of code to get from an 
incoming float to an outgoing one in g_vslider.c.  There's even more math to 
draw the tick and I can't figure out how it works at the moment.

I also love how tempting "log" is for a volume control, but then it silently 
changes a minimum of "0" to max / 100, so you get a runtime error where you 
can't turn the volume down all the way.  Then when you figure out what it did 
you have to add an object to subtract that last little bit, at which point you 
might as well have used [rms] or coded your own algorithm.

-Jonathan




On Tuesday, March 11, 2014 8:08 PM, Alexandre Torres Porres  
wrote:
 
Thanks Jonathan. Unfortunately, my C expertise is kinda poor and I'm still 
lost. I see it's got something to do with [exp] but haven't got my head around 
the function needed to emulate it. I'm making extensive documentation about Pd, 
so I'd like to write about it. I find it worth noting.

In the patch I'm sending, which was my attempt to get this right before 
reaching the list, I was able to emulate a bit reasonably with [expr pow($f1, 
0.25)].

Cheers



2014-03-06 21:56 GMT-03:00 Jonathan Wilkes :

From g_vslider.c:
>
>    if(x->x_lin0_log1)
>    out = x->x_min*exp(x->x_k*(double)(x->x_val)*0.01);
>
>
>Where x->x_k is:
>    log(x->x_max/x->x_min)/(double)(x->x_gui.x_h - 1);
>
>
>And x->x_gui.x_h is the height of the slider
>
>
>-Jonathan
>
>
>
>
>On Thursday, March 6, 2014 7:37 PM, Alexandre Torres Porres  
>wrote:
> 
>hi folks, out of curiosity, what's the exact log function used in the slider? 
>I'd like to emulate it.
>
>
>cheers
>___
>Pd-list@iem.at mailing list
>UNSUBSCRIBE and account-management -> 
>http://lists.puredata.info/listinfo/pd-list
>
>
>___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Tcl invalid command with [TuioClient] and Pd-extended 0.43.4

[Jonathan Wilkes]

On 03/11/2014 12:29 PM, Jack wrote:

Hello,

I need help to understand this problem (see below) and solve it.
It seems to work fine with Pd-Ext 0.42.5 (but not with Pd-Ext 0.43.4).


That leads me to believe it has something to do with the GUI rewrite, 
which happened between 0.42 and 0.43.


Here's the relevant code-- line 90 in source/TUIO/TuioClient.cpp

if (socket!=NULL) {
if (!socket->IsBound()) {
delete socket;
socket = NULL;
} else std::cout << "listening to TUIO messages on UDP 
port " << port << std::endl;

}

***

Somehow std::cout must be printing to the console in 0.42 and sending to 
the gui (i.e., tcl) in 0.43.


If you send a GUI message to tcl it interprets the first word as a 
command.  That's why you get the error below.


I don't know enough about c++ to give you a fix, but I'm sure someone 
else on the list does.


Btw the relevant code is here:
http://sourceforge.net/projects/reactivision/files/TUIO%201.0/TUIO-Clients%201.4/TUIO_PureData-1.4.zip/download?use_mirror=tenet&download=

Then unzip the nested source.zip.

-Jonathan


Thanx.
++

Jack



Le 16/04/2013 12:08, Marco Donnarumma a écrit :

I can confirm, the GUI doesn't show up at all on my machine too.
Linux Lucid 10.04 pd-ext 0.43.4



--
Marco Donnarumma
New Media + Sonic Arts Practitioner, Performer, Teacher, Director.
Embodied Audio-Visual Interaction Research Team.
Department of Computing, Goldsmiths University of London
~
Portfolio: http://marcodonnarumma.com
Research: http://res.marcodonnarumma.com
Director: http://www.liveperformersmeeting.net

Subject: [PD] Tcl invalid command with [TuioClient] and Pd-extended
0.43.4
To: PD List mailto:pd-list@iem.at>>
Message-ID: <516c5543.2070...@rybn.org
>
Content-Type: text/plain; charset="iso-8859-1"

Hello,

I am working on a patch in which i use [TuioClient] with
Pd-extended 0.43.4
When i open this patch, i get in the Pd console :

Invalid command name 'listening'
while executing
"listening to TUIO messages on UDP port "
("uplevel" body line 1)
invoked from within
"uplevel #0 $cmds_from_pd"

Then, very often, there is no GUI and i can't use the patch.
How I can make this patch work (attached) all the time for an
installation (with TuioClient.pd_darwin from tuio.org
) ?

My configuration :
MacMini with MacOSX.7.5
Pd-extended 0.43.4

Thanx.
++

Jack



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




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


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

Re: [PD] 100k lines of code (was libpd separating gui from core)

[Jonathan Wilkes]

On 03/10/2014 12:56 PM, IOhannes m zmölnig wrote:

On 03/10/2014 05:38 PM, Jonathan Wilkes wrote:

Additionally, IOhannes also knows that Miller wants the [initbang] 
functionality in the form of a backwards-compatible [loadbang] which takes 
arguments.
[...]

thanks for the insights.
i didn't know that i knew *that*. i would therefore be interested how i
could have known it.


Sorry, I assumed you read the relevant publicly available thread that 
has messages you authored weaving through it:

http://article.gmane.org/gmane.comp.multimedia.puredata.devel/8611

That's from 2010.  For a patch you submitted in 2006.

We're currently in 2014.

That such a feature would take nearly a decade to get into the professed 
"core" (and still isn't included, in any form) is a symptom of an 
unhealthy development process.  An unhealthy development process keeps 
potential developers from participating and improving the software, 
which is a vicious cycle.


-Jonathan



vcmr
IOhannes



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


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

Re: [PD] 100k lines of code (was libpd separating gui from core)

[Jonathan Wilkes]

In Pd-l2ork:
[dir(
|
[canvasinfo]

And for dir of Pd binary:
[dir(
|
[pdinfo]

And don't take IOhannes' bait.  He's implying that Pd Vanilla is a community 
project-- that if  _we_ coded up a currency converter, or some much more 
pressing functionality, Miller would accept that code.  That is clearly not the 
case.

Additionally, IOhannes also knows that Miller wants the [initbang] 
functionality in the form of a backwards-compatible [loadbang] which takes 
arguments.  Why does he argue with you about priority instead of coding that 
up?  If Pd Vanilla were a community project I'd say, "show me the code".  
Instead, I think he's being prudent and knows from experience that Miller 
doesn't delegate responsibility for new features but instead codes them up 
himself, when he feels like it.  (And evidently with very little priority as 
the [initbang] functionality has been requested for a very long time and data 
structure list fields not at all.)

And that's fine for a personal project like Pd Vanilla or Nyquist.  Those 
authors are kind enough to release their software under a permissive license 
and have never asked for a community of helpers.  It just leads to unnecessary 
frustration when others imply these things are "upstream" from other projects 
and pretend that there's a workable development process centered around them.

-Jonathan




On Monday, March 10, 2014 11:54 AM, Dan Wilcox  wrote:
 
It doesn't have to be a direct include, could be done with any sort of 
mechanism. I do agree that [getdir] is one of the few essential externals I 
still need after I ported my patch lib to vanilla ... that and [stripdir] / 
[splitfilename] but the latter will be possible with the new [list tosymbol] / 
[list fromsymbol] mechanism.


On Mar 10, 2014, at 11:10 AM, i go bananas  wrote:

I'd also like to see [getdir] made vanilla.  There is literally no way to do 
that without the external. 


Dan Wilcox
@danomatika
danomatika.com
robotcowboy.com





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

Re: [PD] change array graph size

[Jonathan Wilkes]

On 03/09/2014 08:15 PM, João Pais wrote:

Hello,

I wanted to change the graph canvas of an array, but I can't find the
way of doing it. If I have an array called "array1", to where should I
send a coords message? Does it work like a normal GOP?


The graph is named "graph$n", where $n is incremented for each graph 
that exists in the Pd instance.  So you'd send to "pd-graph$n" in order 
to do that.


In Pd-l2ork you just move the mouse down to the bottom-right corner of 
the "Put" menu array, and you get a cursor that lets you click-drag the 
graph to change its size.


-Jonathan



Thanks,

jmmmp

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





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

Re: [PD] Data structures and click event

[Jonathan Wilkes]

On 03/08/2014 12:46 PM, Dan Wilcox wrote:


On Mar 8, 2014, at 5:59 AM, pd-list-requ...@iem.at 
 wrote:




No.  It requires a toolkit that has modern 2d features like affine 
transformations and opacity, etc.  Pd-l2ork leverages Tkpath, a 
tcl/tk library.  Other modern toolkits like Qt have their own 2d 
interfaces with the same features and could be used, but tcl/tk on 
its own does not.



for the non-unix users out there?


For OSX, one of the tcl/tk libraries-- Tkpath needs to be ported from 
Carbon to Cocoa.


I have this about halfway done. I finally found the old QuickTime 
Carbon headers so I could port the old school font creation to 
CoreText. All of the old Quick Draw stuff is no longer on the Apple 
Developer docs, so it was a bit confusing at first. It will take a 
little while though since I dip into it now and then among everything 
else.


Hey that's great!

I can probably help once you get that part ready.  One issue will be to 
making sure everything builds using a newer version of tcl/tk than what 
Pd-extended currently ships with.  It might be good just to go ahead and 
try 8.6 since it has some new tk::mac goodies.




I haven't investigated a Windows port yet but it's probably mostly a 
matter of setting up the proper compile environment more than 
anything else.  Granted one would probably need to tweak pd.tk and 
L2ork's build script, but getting set up in Windows seems to be where 
most of the work is.  (At least in my experience so far.)


It shouldn't require too much beyond the current steps to build 
vanilla or extended on Windows: a mingw + msys enviornent. Tkpath uses 
an autoconf build system so it should be fine on Windows as long as 
you point it to the tcl/tk headers. The issue with OSX is that it 
simple hasn't been updated in a while but I imagine it's fine on 
Windows since MS moves very very slowly as far as moving to new APIs 
is concerned.


There are a few other tk libs Pd-l2ork uses.  I'm also assuming Tkpath 
doesn't have any crashers in Windows-- I haven't tried it yet.


-Jonathan




Dan Wilcox
@danomatika
danomatika.com 
robotcowboy.com 







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

Re: [PD] Data structures and click event

[Jonathan Wilkes]

On 03/07/2014 06:45 PM, João Pais wrote:



On 03/05/2014 05:24 AM, Pierre Massat wrote:

Dear list,

First of all i'd like to say that i'm very impressed by the
potential of data structures in Pd. I've always kind of ignored
this feature and it's a pity because it's really worth diving
into it.
That being said I think that help and example patches are far
from sufficient for beginners, and if it wasn't for Chris
McCormick's s-abstractions I would have been able to really
figure out how to use them (stuff like how to make an entire
polygon draggable, how to use GOP with proper scaling, etc.).


It's not just the documentation, it's the interface.  Having to
walk linked-lists of graphically unlinked objects is bad. Having
to use boilerplate to find the head of a glist just to create a
scalar is bad.

  I think Pd-l2ork is getting close to a release with my new data
structure stuff in it.  It's a first step at addressing some of
these issues.


and any prospects of that stuff making it into vanilla or pd-ext,


No.  It requires a toolkit that has modern 2d features like affine 
transformations and opacity, etc.  Pd-l2ork leverages Tkpath, a tcl/tk 
library.  Other modern toolkits like Qt have their own 2d interfaces 
with the same features and could be used, but tcl/tk on its own does not.



for the non-unix users out there?


For OSX, one of the tcl/tk libraries-- Tkpath needs to be ported from 
Carbon to Cocoa.


I haven't investigated a Windows port yet but it's probably mostly a 
matter of setting up the proper compile environment more than anything 
else.  Granted one would probably need to tweak pd.tk and L2ork's build 
script, but getting set up in Windows seems to be where most of the work 
is.  (At least in my experience so far.)


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

Re: [PD] log function in slider

[Jonathan Wilkes]

>From g_vslider.c:

    if(x->x_lin0_log1)
    out = x->x_min*exp(x->x_k*(double)(x->x_val)*0.01);


Where x->x_k is:
    log(x->x_max/x->x_min)/(double)(x->x_gui.x_h - 1);


And x->x_gui.x_h is the height of the slider

-Jonathan




On Thursday, March 6, 2014 7:37 PM, Alexandre Torres Porres  
wrote:
 
hi folks, out of curiosity, what's the exact log function used in the slider? 
I'd like to emulate it.

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

Re: [PD] arrays in GOP abstraction, show up in parent patch

[Jonathan Wilkes]

Shows up in Pd Vanilla.

Doesn't show up in Pd-l2ork (latest build from git).

-Jonathan





On Thursday, March 6, 2014 10:32 AM, Jaime E Oliver  
wrote:
 
Hi all, 

The title says it all, 

I have some arrays in abstractions and any new value input into the array is 
also graphed in the parent patch. This happens in OS X 10.8.5 w/latest pd. It 
does not happen with 0.42-5.

testing patch attached.

best,

J

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

Re: [PD] Pd as sound editor (issue with "scrolling" a table) ??

[Jonathan Wilkes]

On 03/05/2014 04:36 AM, i go bananas wrote:
>>Remember that when you redraw an element of an array you actually 
redraw the _entire_ array in Pd Vanilla.  And depending on the array 
style you may have a separate tk canvas item for each element.<<


why do the iem tab objects work so much better then?


I haven't looked at the code, but I'd imagine those externals do some 
array-wide operation then trigger a single redraw of the entire array.  
For a 100-element array that'd be 100x faster.


But if you want the GUI to look modern you want the chunk of samples 
you're displacing to redraw ASAP.  For that Pd (Vanilla) still needs to 
continually delete and redraw the array as you click-drag the 
selection.  So it's better than the worst of all possible worlds-- using 
[tabwrite]-- but still extremely inefficient (not to mention it doesn't 
scale).


To be fair, it's unclear how to "do this right" even with a "clean" 
separation of GUI/core.  It's unclear what "clean" means, and it's 
unclear what "this" is.


To be specific: it's really hard to predict what purpose the user will 
find for the realtime audio engine when the GUI is also a programming 
language.  For example, you can get all kinds of speedups in a DAW by 
waiting for the user to release the mouse button when displacing a 
selection.  But if you did that by default for "Put" menu arrays you'd 
ruin several of Miller's tutorials, where an immediate connection 
between visual array change and audio change is vital if inefficient.


-Jonathan

 maelstorm said that it was incredibly slow using an [until] based 
counter, but worked smoothly with the iem objects.  This was for 
EXACTLY the same gui, so i'm not really sure if it's a gui redraw issue.


Then again, he also said that the iem tabs objects seem to process 
tables in chunks...so maybe the gui is also only redrawn in those 
chunk sizes?  that would make sense i guess.





On Wed, Mar 5, 2014 at 10:35 AM, Billy Stiltner 
mailto:billy.stilt...@gmail.com>> wrote:


"So when you use the [until] loop you are sending drawing
instructions to the GUI ($arraysize * $no_mouse_events) times.  A
single array redraw instruction in tcl is about 4k, so to scroll a
single pixel for a 100-element array:
100 elements * 1 = 100 redraws * 4k = 400k"

thats why i say fix tcl/tk
my old graphics library could be used for a new gui. it is c++ but
has the logic to even only update lines as in blit an arbitrary line.


On Tue, Mar 4, 2014 at 1:33 PM, Jonathan Wilkes
mailto:jancs...@yahoo.com>> wrote:

On 03/04/2014 01:20 PM, Jonathan Wilkes wrote:

On 03/04/2014 10:11 AM, i go bananas wrote:

[...]




2014-03-04 12:12 GMT+01:00 i go bananas
mailto:hard@gmail.com>>:

just for interest perhaps, here's the sound editor i
made years ago:

http://puredata.hurleur.com/sujet-1295-sound-editor

and probably even more interesting, here is
maelstorm's wave display abstraction:

http://puredata.hurleur.com/sujet-5890-waveform-display



basically, what maelstorm discovered was that using
[until] with a counter was not nearly fast enough to
do the calculations needed for a decent zoom/scroll
function, and we looked into it, and there just
didn't seem to be a vanilla workaround.  So he uses
iem_tab objects to do the table calculations.



Remember that when you redraw an element of an array you
actually redraw the _entire_ array in Pd Vanilla.  And
depending on the array style you may have a separate tk
canvas item for each element.

So when you use the [until] loop you are sending drawing
instructions to the GUI ($arraysize * $no_mouse_events)
times.  A single array redraw instruction in tcl is about 4k,
so to scroll a single pixel for a 100-element array:
100 elements * 1 = 100 redraws * 4k = 400k

That's flowing from the core to the GUI for a _single_ mouse
event.  If you trigger ten scrolls you're already at 4 megs
of data sent.

I'm pretty sure commercial editors avoid that type of
design.  In editors like the upcoming Openshot Video that
have several discrete parts that sending messages, the GUI
part almost certainly sends nothing at all to the video core
for zooming/scrolling.  For moving a chunk of audio/video, it
almost certainly sends a single message about a single
object's delta.


I may have showed this already, but I think it's instructive here:
https://jwilkes.nfshost

Re: [PD] Data structures and click event

[Jonathan Wilkes]

On 03/05/2014 05:24 AM, Pierre Massat wrote:

Dear list,

First of all i'd like to say that i'm very impressed by the potential 
of data structures in Pd. I've always kind of ignored this feature and 
it's a pity because it's really worth diving into it.
That being said I think that help and example patches are far from 
sufficient for beginners, and if it wasn't for Chris McCormick's 
s-abstractions I would have been able to really figure out how to use 
them (stuff like how to make an entire polygon draggable, how to use 
GOP with proper scaling, etc.).


It's not just the documentation, it's the interface.  Having to walk 
linked-lists of graphically unlinked objects is bad.  Having to use 
boilerplate to find the head of a glist just to create a scalar is bad.


I think Pd-l2ork is getting close to a release with my new data 
structure stuff in it.  It's a first step at addressing some of these 
issues.


-Jonathan



I m now stuck with a question. How can I identify the element which 
was just clicked ? I know that [struc] outputs the events, like click, 
selection and change, but I thought I could identify individual 
elements by their pointer id. It turns out that I get the same pointer 
for every element, although I created them sequentially (using [append]).


(I guess something must be escaping me about pointers... I've noticed 
that within the same template, I get different pointers for elements 
on different y-levels, but the same pointer for all the element on the 
same y-level regardless of their x.)


Cheers,

Pierre


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


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

Re: [PD] Get name of patch from within the patch

[Jonathan Wilkes]

But it also precedes the search-plugin.


-Jonathan




On Tuesday, March 4, 2014 3:59 PM, Ivica Bukvic  wrote:
 
Except that in this case patch_name precedes  canvasinfo...
On Mar 4, 2014 3:01 PM, "Jonathan Wilkes"  wrote:

On 03/04/2014 01:15 PM, Ivica Bukvic wrote:
>
>...and [patch_name] external (again pd-l2ork only) that outputs the filepath 
>out of the left outlet and the patch filename out of the right outlet.
>There's also
>
>[patchname $1(
>|
>[duplicate_effort]
>
>Just fill $1 with the name of the object you want to create, and
[duplicate_effort] will automatically compile another class with
that name and with the functionality you want.
>
>Currently [duplicate_effort] supports the following methods:
>
>patchname
>dollarargs
>abs~
>pow~
>bandlimited_grabbag
>arraysize
>mousecoords
>count
>string
>duplicate_effort
>
>Each class created is guaranteed to be unique so you can use it to
create private keys.  You can also give it an extra float argument
to specify help patch quality.  (All values default to zero.)
>
>To download a copy, start a repo in github and code up another
version of it.
>
>-Jonathan
>
>
>On Mar 4, 2014 12:47 PM, "Jonathan Wilkes"  wrote:
>>
>>On 03/04/2014 03:00 AM, Kaj Ailomaa wrote:
>>>
>>>
>>>>On Tue, Mar 4, 2014, at 02:54 AM, Chris McCormick wrote:
>>>>
>>>>Hello,
>>>>>
>>>>>On 03/03/14 21:55, Kaj Ailomaa wrote:
>>>>>
>>>>>Hi. I've been googling a bit and looking through the library of objects
>>>>>>that comes with pd-extended, but can't seem to find a
way to get the
>>>>>>name of the patch from within the patch. Anyone know of
a nice method to
>>>>>>do this?
>>>>>>
I would use [namecanvas] for this. For example you could have an object
>>>>>like [namecanvas $0-mypatch] and then you can send
  messages to the patch
>>>>>using e.g. [s $0-mypatch].
>>>>>
>>>>>
Thanks, but this won't work for me, as the name has to be the actual
>>>>patch name.
>>>>
>>>>I've understood that there might be a fix in the svn version
of
>>>>[canvasname], apart of iemguts, which would allow getting
the name of
>>>>the top level patch.
>>>>
>>>>The reason I had for this is I wanted to have uniquely named
patches
>>>>that have a common save mechanism, which looks up the
savefile based on
>>>>the unique patch name.
>>>>I was always going to create these uniquely named patches in
another top
>>>>level patch, so I can get around this problems by adding an
argument for
>>>>the patch, which is the same as the patchname, and let the
save
>>>>mechanism look up the filename that way.
>>>>
>>>>I initially would have wanted the uniquely named patch to be
able to be
>>>>opened as is, but that's not a major problem.
>>>>
>>>Currently I think the only way to do this is
  [filename(---[canvasinfo], which is only in Pd-l2ork.
>>>
>>>-Jonathan
>>>
>>>
>>>
>>>>___
>>>>Pd-list@iem.at mailing list
>>>>UNSUBSCRIBE and account-management -> 
>>>>http://lists.puredata.info/listinfo/pd-list
>>>>
>>>>
>>>>
>>>
>>>___
>>>Pd-list@iem.at mailing list
>>>UNSUBSCRIBE and account-management -> 
>>>http://lists.puredata.info/listinfo/pd-list
>>>
>___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Get name of patch from within the patch

[Jonathan Wilkes]

On 03/04/2014 01:15 PM, Ivica Bukvic wrote:


...and [patch_name] external (again pd-l2ork only) that outputs the 
filepath out of the left outlet and the patch filename out of the 
right outlet.




There's also

[patchname $1(
|
[duplicate_effort]

Just fill $1 with the name of the object you want to create, and 
[duplicate_effort] will automatically compile another class with that 
name and with the functionality you want.


Currently [duplicate_effort] supports the following methods:

patchname
dollarargs
abs~
pow~
bandlimited_grabbag
arraysize
mousecoords
count
string
duplicate_effort

Each class created is guaranteed to be unique so you can use it to 
create private keys.  You can also give it an extra float argument to 
specify help patch quality.  (All values default to zero.)


To download a copy, start a repo in github and code up another version 
of it.


-Jonathan

On Mar 4, 2014 12:47 PM, "Jonathan Wilkes" <mailto:jancs...@yahoo.com>> wrote:


On 03/04/2014 03:00 AM, Kaj Ailomaa wrote:


On Tue, Mar 4, 2014, at 02:54 AM, Chris McCormick wrote:

Hello,

On 03/03/14 21:55, Kaj Ailomaa wrote:

Hi. I've been googling a bit and looking through the
library of objects
that comes with pd-extended, but can't seem to find a
way to get the
name of the patch from within the patch. Anyone know
of a nice method to
do this?

I would use [namecanvas] for this. For example you could
have an object
like [namecanvas $0-mypatch] and then you can send
messages to the patch
using e.g. [s $0-mypatch].

Thanks, but this won't work for me, as the name has to be the
actual
patch name.

I've understood that there might be a fix in the svn version of
[canvasname], apart of iemguts, which would allow getting the
name of
the top level patch.

The reason I had for this is I wanted to have uniquely named
patches
that have a common save mechanism, which looks up the savefile
based on
the unique patch name.
I was always going to create these uniquely named patches in
another top
level patch, so I can get around this problems by adding an
argument for
the patch, which is the same as the patchname, and let the save
mechanism look up the filename that way.

I initially would have wanted the uniquely named patch to be
able to be
opened as is, but that's not a major problem.


Currently I think the only way to do this is
[filename(---[canvasinfo], which is only in Pd-l2ork.

-Jonathan


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




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



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

Re: [PD] Pd as sound editor (issue with "scrolling" a table) ??

[Jonathan Wilkes]

On 03/04/2014 01:20 PM, Jonathan Wilkes wrote:

On 03/04/2014 10:11 AM, i go bananas wrote:

[...]




2014-03-04 12:12 GMT+01:00 i go bananas mailto:hard@gmail.com>>:

just for interest perhaps, here's the sound editor i made
years ago:

http://puredata.hurleur.com/sujet-1295-sound-editor

and probably even more interesting, here is maelstorm's wave
display abstraction:

http://puredata.hurleur.com/sujet-5890-waveform-display



basically, what maelstorm discovered was that using [until]
with a counter was not nearly fast enough to do the
calculations needed for a decent zoom/scroll function, and we
looked into it, and there just didn't seem to be a vanilla
workaround.  So he uses iem_tab objects to do the table
calculations.



Remember that when you redraw an element of an array you actually 
redraw the _entire_ array in Pd Vanilla.  And depending on the array 
style you may have a separate tk canvas item for each element.


So when you use the [until] loop you are sending drawing instructions 
to the GUI ($arraysize * $no_mouse_events) times.  A single array 
redraw instruction in tcl is about 4k, so to scroll a single pixel for 
a 100-element array:

100 elements * 1 = 100 redraws * 4k = 400k

That's flowing from the core to the GUI for a _single_ mouse event.  
If you trigger ten scrolls you're already at 4 megs of data sent.


I'm pretty sure commercial editors avoid that type of design.  In 
editors like the upcoming Openshot Video that have several discrete 
parts that sending messages, the GUI part almost certainly sends 
nothing at all to the video core for zooming/scrolling.  For moving a 
chunk of audio/video, it almost certainly sends a single message about 
a single object's delta.


I may have showed this already, but I think it's instructive here:
https://jwilkes.nfshost.com/pd-tiger.webm

I don't have sound on that clip, but I believe I tried it with the "test 
audio" patch going and I wasn't getting dropouts.  This is because a) 
I'm sending a single transform message for every scroll of the number 
box and b) the GUI toolkit-- not Pd core-- is doing the math to 
transform and redisplay the drawing.


Socket traffic is bad because it require both the core (sending) and GUI 
(receiving) to do work.  If you generate megs and megs of traffic you 
can end up with dropouts and choking display even if there's very little 
being redrawn.


-Jonathan



-Jonathan




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


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

Re: [PD] Pd as sound editor (issue with "scrolling" a table) ??

[Jonathan Wilkes]

On 03/04/2014 10:11 AM, i go bananas wrote:

[...]




2014-03-04 12:12 GMT+01:00 i go bananas mailto:hard@gmail.com>>:

just for interest perhaps, here's the sound editor i made
years ago:

http://puredata.hurleur.com/sujet-1295-sound-editor

and probably even more interesting, here is maelstorm's wave
display abstraction:

http://puredata.hurleur.com/sujet-5890-waveform-display



basically, what maelstorm discovered was that using [until]
with a counter was not nearly fast enough to do the
calculations needed for a decent zoom/scroll function, and we
looked into it, and there just didn't seem to be a vanilla
workaround.  So he uses iem_tab objects to do the table
calculations.



Remember that when you redraw an element of an array you actually redraw 
the _entire_ array in Pd Vanilla.  And depending on the array style you 
may have a separate tk canvas item for each element.


So when you use the [until] loop you are sending drawing instructions to 
the GUI ($arraysize * $no_mouse_events) times.  A single array redraw 
instruction in tcl is about 4k, so to scroll a single pixel for a 
100-element array:

100 elements * 1 = 100 redraws * 4k = 400k

That's flowing from the core to the GUI for a _single_ mouse event. If 
you trigger ten scrolls you're already at 4 megs of data sent.


I'm pretty sure commercial editors avoid that type of design.  In 
editors like the upcoming Openshot Video that have several discrete 
parts that sending messages, the GUI part almost certainly sends nothing 
at all to the video core for zooming/scrolling.  For moving a chunk of 
audio/video, it almost certainly sends a single message about a single 
object's delta.


-Jonathan


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

Re: [PD] Get name of patch from within the patch

[Jonathan Wilkes]

On 03/04/2014 03:00 AM, Kaj Ailomaa wrote:


On Tue, Mar 4, 2014, at 02:54 AM, Chris McCormick wrote:

Hello,

On 03/03/14 21:55, Kaj Ailomaa wrote:

Hi. I've been googling a bit and looking through the library of objects
that comes with pd-extended, but can't seem to find a way to get the
name of the patch from within the patch. Anyone know of a nice method to
do this?

I would use [namecanvas] for this. For example you could have an object
like [namecanvas $0-mypatch] and then you can send messages to the patch
using e.g. [s $0-mypatch].


Thanks, but this won't work for me, as the name has to be the actual
patch name.

I've understood that there might be a fix in the svn version of
[canvasname], apart of iemguts, which would allow getting the name of
the top level patch.

The reason I had for this is I wanted to have uniquely named patches
that have a common save mechanism, which looks up the savefile based on
the unique patch name.
I was always going to create these uniquely named patches in another top
level patch, so I can get around this problems by adding an argument for
the patch, which is the same as the patchname, and let the save
mechanism look up the filename that way.

I initially would have wanted the uniquely named patch to be able to be
opened as is, but that's not a major problem.


Currently I think the only way to do this is [filename(---[canvasinfo], 
which is only in Pd-l2ork.


-Jonathan



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





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

Re: [PD] jack and callbacks

[Jonathan Wilkes]

On 03/03/2014 07:44 PM, Peter P. wrote:

Hi,

just learned that my Pd vanilla Pd-0.45.0 from Miller's Git sources
works "much better" (less drop outs, etc) under jack when enabling
"use callbacks".

Is there a way to enable this worthy parameter from the command line?
Perhaps a way of setting it statically, maybe in s_audio_jack.c ?


Is there any documentation about "enable callbacks" outside of being 
littered throughout the list?


Two more questions:
Isn't Jack's API callback-based?  What does it mean to use Jack without 
enabling callbacks?


-Jonathan



Thank you and enjoy!
Peter

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





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

Re: [PD] Pd as sound editor (issue with "scrolling" a table) ??

[Jonathan Wilkes]

On 03/03/2014 01:32 PM, Pierre Massat wrote:
I've looked seriously at data structures for the first time, and saw 
what Chris McCormick did with them, and I believe this is the way to go !


But you can't get notifications for mouseover or right-click events.  
You also cannot get transparency or control the z-order among multiple 
scalars.  Nor scale or zoom without creating another complex and slow 
wrapper on top of data structures.


Don't get me wrong-- you can do interesting things with scalars, and you 
can build a wave-editor that looks quite advanced compared to what a GUI 
in Pd typically looks like.  But you cannot get anything that looks 
remotely like a modern or even decade-old commercial wave-editor.


So I'd rather the documentation didn't send people searching around the 
corners of the software for features that don't exist.


-Jonathan



Cheers,

Pierre.


2014-03-03 8:44 GMT+01:00 Billy Stiltner <mailto:billy.stilt...@gmail.com>>:


seems like there was something about the way i made the wave
editor that worked,i  never tried overflowing the the things and
my method is a hack of the pd file @xensynth and the lfo editor,
otherwise holler at Mike Booth ala mmb.


https://archive.org/search.php?query=uploader%3A%22billy.stiltner%40gmail.com%22&sort=-publicdate



On Mon, Mar 3, 2014 at 2:34 AM, Pierre Massat mailto:pimas...@gmail.com>> wrote:

Hi Jonathan,

I found it following this path : help for [tabwrite] -->
More_Info --> all_about_arrays --> Common uses for arrays in Pd
Bummer, I thought somebody would come up with a secret table
manipulation technique that would make this statement true...

Cheers,

    Pierre.


2014-03-02 19:33 GMT+01:00 Jonathan Wilkes mailto:jancs...@yahoo.com>>:

From that help patch:
#X text 12 115 HELP_PATCH_AUTHORS Updated for Pd 0.38-2.
Jonathan Wilkes
revised the patch to conform to the PDDP template for Pd
version 0.42.

I did the refactoring of that patch, but I'm not sure who
wrote what you're quoting.

I'd say that statement is false and should be removed.

-Jonathan


On Sunday, March 2, 2014 10:47 AM, Pierre Massat
mailto:pimas...@gmail.com>> wrote:
Dear list,

I am working on a small patch which stores simple events
in a table to trigger sounds later on.
I would like to be able to edit the content of my table
easily, which requires scrolling it, zooming in, and
eventually editing the content.

I have found away of scrolling the content, but it is very
slow with relatively big tables (hem, even with a table
with 20 000 samples...). Please see the example attached.

I have 2 questions :
1) Is there a more efficient way of doing this ? Copying
only part of the content is worse (i've tried).
2) Can I prevent the content of the table from spilling
over the table to right of the left ? I get the same
behaviour in a GOP, and putting a canvas next to the table
to cover it doesn't work because the table content gets
redrawn on top of it.

This leads me to a more general question about something
i've found in the help :
"5 Wave editing: with proper manipulation of array data,
Pd can be fully functional wave editor, complete with
mouse-clickable cut-n-paste, pitch-shift, time expansion,
down/upsampling, and other tools typically found in
commercial wave editors."
This has always sounded very appealing to me, but i wonder
how realistic this statement is... unless i'm ignoring 80
% of what can be done with tables in Pd.

Cheers,

Pierre.

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




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





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

Re: [PD] Pd as sound editor (issue with "scrolling" a table) ??

[Jonathan Wilkes]

On 03/03/2014 02:44 AM, Billy Stiltner wrote:
seems like there was something about the way i made the wave editor 
that worked,i  never tried overflowing the the things and my method is 
a hack of the pd file @xensynth and the lfo editor, otherwise holler 
at Mike Booth ala mmb.


You can make a wave editor.  You just cannot make a wave editor that has 
the tools typically found in commercial wave editors, unless you 
systematically ignore the modern/sophisticated GUI systems which make 
commercial wave editors efficient to use.


-Jonahan



https://archive.org/search.php?query=uploader%3A%22billy.stiltner%40gmail.com%22&sort=-publicdate 




On Mon, Mar 3, 2014 at 2:34 AM, Pierre Massat <mailto:pimas...@gmail.com>> wrote:


Hi Jonathan,

I found it following this path : help for [tabwrite] --> More_Info
--> all_about_arrays --> Common uses for arrays in Pd
Bummer, I thought somebody would come up with a secret table
manipulation technique that would make this statement true...

Cheers,

Pierre.


2014-03-02 19:33 GMT+01:00 Jonathan Wilkes mailto:jancs...@yahoo.com>>:

From that help patch:
#X text 12 115 HELP_PATCH_AUTHORS Updated for Pd 0.38-2.
Jonathan Wilkes
revised the patch to conform to the PDDP template for Pd
version 0.42.

I did the refactoring of that patch, but I'm not sure who
wrote what you're quoting.

I'd say that statement is false and should be removed.

-Jonathan


On Sunday, March 2, 2014 10:47 AM, Pierre Massat
mailto:pimas...@gmail.com>> wrote:
Dear list,

I am working on a small patch which stores simple events in a
table to trigger sounds later on.
I would like to be able to edit the content of my table
easily, which requires scrolling it, zooming in, and
eventually editing the content.

I have found away of scrolling the content, but it is very
slow with relatively big tables (hem, even with a table with
20 000 samples...). Please see the example attached.

I have 2 questions :
1) Is there a more efficient way of doing this ? Copying only
part of the content is worse (i've tried).
2) Can I prevent the content of the table from spilling over
the table to right of the left ? I get the same behaviour in a
GOP, and putting a canvas next to the table to cover it
doesn't work because the table content gets redrawn on top of it.

This leads me to a more general question about something i've
found in the help :
"5 Wave editing: with proper manipulation of array data, Pd
can be fully functional wave editor, complete with
mouse-clickable cut-n-paste, pitch-shift, time expansion,
down/upsampling, and other tools typically found in commercial
wave editors."
This has always sounded very appealing to me, but i wonder how
realistic this statement is... unless i'm ignoring 80 % of
what can be done with tables in Pd.

Cheers,

Pierre.

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




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




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

Re: [PD] Get name of patch from within the patch

[Jonathan Wilkes]

In Pd-l2ork, you can do [filename(---[canvasinfo].

But I'm still working on that interface.  For example, itgives you the name 
without the extension ".pd".  But maybe it should include that extention, too.

In Pd-extended, I'm not sure how to do that.  There's [iemguts/canvasname], but 
it doesn't give return anything for a toplevel patch.


-Jonathan




On Monday, March 3, 2014 9:11 AM, Kaj Ailomaa  wrote:
 
Hi. I've been googling a bit and looking through the library of objects
that comes with pd-extended, but can't seem to find a way to get the
name of the patch from within the patch. Anyone know of a nice method to
do this?

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

Re: [PD] Pd as sound editor (issue with "scrolling" a table) ??

[Jonathan Wilkes]

>From that help patch:
#X text 12 115 HELP_PATCH_AUTHORS Updated for Pd 0.38-2. Jonathan Wilkes
revised the patch to conform to the PDDP template for Pd version 0.42.

I did the refactoring of that patch, but I'm not sure who wrote what you're 
quoting.

I'd say that statement is false and should be removed.

-Jonathan




On Sunday, March 2, 2014 10:47 AM, Pierre Massat  wrote:
 
Dear list,

I am working on a small
 patch which stores simple events in a table to trigger sounds later on. 
I would like to be able to edit the content of my table easily, which requires 
scrolling it, zooming in, and eventually editing the content.

I have found away of scrolling the content, but it is very slow with relatively 
big tables (hem, even with a table with 20 000 samples...). Please see the 
example attached.


I have 2 questions :
1) Is there a more efficient way of doing this ? Copying only part of the 
content is worse (i've tried).
2) Can I prevent the content of the table from spilling over the table to right 
of the left ? I get the same behaviour in a GOP, and putting a canvas next to 
the table to cover it doesn't work because the table content gets redrawn on 
top of it.

This leads me to a more general question about something i've found in the help 
: 
"5 Wave editing: with proper manipulation of array data, Pd can be fully 
functional wave editor, complete with mouse-clickable cut-n-paste, pitch-shift, 
time expansion, down/upsampling, and other tools typically found in commercial 
wave editors."
This has always sounded very appealing to me, but i wonder how realistic this 
statement is... unless i'm ignoring 80 % of what can be done with tables in Pd.

Cheers,

Pierre.

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

Re: [PD] easing in pd

[Jonathan Wilkes]

I refactored a bunch of the easing styles from Raphael.js to use with data 
structures (attached).  Look in [pd movers] and then [pd animate].

The patch itself only works in Pd-l2ork, but you can break out all of the 
animation logic.  You'll just need to replace any instance of [pi(--[pdinfo], 
with the value of Pi.  (I should probably get rid of that anyway.)

Here's a video:
jonathanwilkes.net/easing.webm






On Wednesday, February 26, 2014 4:00 PM, Alexandros Drymonitis 
 wrote:
 
The mapping library is very likely to have stuff that would be helpful to you, 
I guess..




On Wed, Feb 26, 2014 at 10:42 PM, David Schaffer  
wrote:

Hi , 
>
>I was wonderning if anyone of you had tried to implement easing in pd. I'm 
>working on a video animation patch that uses "random" objects and the result 
>would look much better if I could find a way to "smooth" the transitions. I 
>already use the "line" object, but I'm looking for a way to slow down the line 
>output when the line comes to its end, then start smoothly when it has a new 
>target value. I'm thinking of using the expr object but I would be grateful if 
>someone could give me some design hints on this...
>
>Thank you very much,
>
>D.S
>
>
>http://www.flickr.com/photos/schafferdavid/
>https://soundcloud.com/schafferdavid
>
>___
>Pd-list@iem.at mailing list
>UNSUBSCRIBE and account-management -> 
>http://lists.puredata.info/listinfo/pd-list
>
>

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

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

Re: [PD] libpd separating gui from core

[Jonathan Wilkes]

t) threads of people essentially daydreaming in 
detail about new directions for the software to take, without producing 
any code because they _know_ from experience it would just end up 
rotting on the tracker.


I'm not saying the "upstream" maintainer has to be you, Peter.  But it 
has to be somebody.  I'm happy to recount the details of why there's a 
Pd-l2ork and how it's different from Pd-extended, but if no one is 
willing to say they will do the work of listening, reviewing, and 
delegating work on an "upstream" core then we're just dancing around the 
real problem.


-Jonathan


Cheers,
 Peter




On Mon, Feb 24, 2014 at 8:12 PM, Billy Stiltner 
mailto:billy.stilt...@gmail.com>> wrote:


I think Miller's  puredata is awesome. more than 20 years ago I
wrote my own assembly routines as well as c++ for an analog
devices 32 ch board for waterplant control software , but ended up
using the factory drivers instead when they came out for this
software
http://home.comcast.net/~patslabtech/Applications/seatbelt_testing.html
<http://home.comcast.net/%7Epatslabtech/Applications/seatbelt_testing.html>.
reminds me more of reaktor than puredata. I  have a hard time
comprehending reaktor stuff but things make so much more since
using pd.
I ought do dig into the programming part of pd . I read a lot of
the code and it's kinda starting to sink in how to write an
external, it's not quite like on the tip of my toungue yet though.


On Mon, Feb 24, 2014 at 7:08 PM, Jonathan Wilkes
mailto:jancs...@yahoo.com>> wrote:

On 02/24/2014 03:03 PM, Dan Wilcox wrote:

Exactly. If we can build a list of things that
should/could be in the core, then we have a starting place
to see if there is a way to work into into either vanilla
or a wrapper like libpd.


Let's just focus on a single feature-- "$@"-- and assume that
there is widespread desire for such a feature by most Pd users.

How do we put this feature into a wrapper like libpd?  The
only thing I can think of is as part of a patch set that get
applied to core Vanilla, and that's hard to maintain.

As for working stuff into Vanilla-- that's Miller's personal
version of Pd, and I've never once seen him state that it's
the reference client, or that it's at the top of any
hierarchy.  All I've seen is passive-aggressive statements
from other devs on this list who say, "You'll have to ask
Miller if you want to get 'whatever' in Vanilla," when I ask
about the kind of issues you're talking about. Of course I
can't be certain but I'd guess that style of non-development
is probably one of the biggest sources of your frustration.

But I really will help you implement whatever it is you think
improves sustainable development for Pd.  I really, really
don't want to extract patches from the 1000+ commits in
Pd-l2ork (granted the core/non-graphical changes would be
fewer), but I'll help you do it if that's the path you want to
take.

-Jonathan


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



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




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

Re: [PD] Bugs in Pd-Extended in Ubuntu LTS

[Jonathan Wilkes]

1) Are you starting JACK before firing up Pd-extended?
2) Are you typing any non-ascii characters?  If so what are they?

-Jonathan





On Tuesday, February 25, 2014 1:54 PM, Pierre Massat  wrote:
 
Dear list,

I've been using Pd-extended in Ubuntu LTS (12.04) a lot lately, and a couple of 
bugs are beginning to get on my nerves...
first it randomly crashes and also crashes X (i get a black screen, and after a 
few seconds i'm prompted for my password to log into my session again), 
whenever I'm typing something in an object box (i haven't been able to figure 
out exaclty what character was causing this, it really looks random to me).
I also get constant error messages in the console when using JACK (JACKerror: 
Cannot use real-time scheduling (RR/55)(1: Operation not permitted)
JACKerror: JackClient::AcquireSelfRealTime error). The sound works sometimes 
though, but Pd also freezes every once in a while. I also get error messages 
with Alsa.

I have installed Pd-extended from the Ubuntu repos. It seems to be the same 
version as the one available on puredata.info (0.43.4).

I don't know what to do.

Cheers,

Pierre.

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

Re: [PD] libpd separating gui from core

[Jonathan Wilkes]

On 02/24/2014 03:03 PM, Dan Wilcox wrote:
Exactly. If we can build a list of things that should/could be in the 
core, then we have a starting place to see if there is a way to work 
into into either vanilla or a wrapper like libpd.


Let's just focus on a single feature-- "$@"-- and assume that there is 
widespread desire for such a feature by most Pd users.


How do we put this feature into a wrapper like libpd?  The only thing I 
can think of is as part of a patch set that get applied to core Vanilla, 
and that's hard to maintain.


As for working stuff into Vanilla-- that's Miller's personal version of 
Pd, and I've never once seen him state that it's the reference client, 
or that it's at the top of any hierarchy.  All I've seen is 
passive-aggressive statements from other devs on this list who say, 
"You'll have to ask Miller if you want to get 'whatever' in Vanilla," 
when I ask about the kind of issues you're talking about. Of course I 
can't be certain but I'd guess that style of non-development is probably 
one of the biggest sources of your frustration.


But I really will help you implement whatever it is you think improves 
sustainable development for Pd.  I really, really don't want to extract 
patches from the 1000+ commits in Pd-l2ork (granted the 
core/non-graphical changes would be fewer), but I'll help you do it if 
that's the path you want to take.


-Jonathan

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

Re: [PD] libpd separating gui from core

[Jonathan Wilkes]

Oops-- by "arguments of the parent" I mean arguments of the parent abstraction.

-Jonathan





On Monday, February 24, 2014 2:44 PM, Jonathan Wilkes  
wrote:
 
So let's just take a concrete example: "$@" syntax.  It is a dollarsign 
variable in Pd-l2ork (and maybe in Pd-extended-- can't remember) and it expands 
to the incoming arguments.  In an object box this expands to the arguments of 
the parent.  The code for this feature affects Pd's message parser, which is in 
"the core".  This is just an example-- there is a whole category of features 
which require changes to core code like this one.

If you have a description of a democratic development process that can 
implement such a feature by wrapping Pd Vanilla in a GUI wrapper, document how 
it works, and
 if it's maintainable I'll help you implement it.

-Jonathan



On Monday, February 24, 2014 1:56 PM, Ivica Ico Bukvic  wrote:
 
 
 
From:Dan Wilcox [mailto:danomat...@gmail.com] 
Sent: Monday, February 24, 2014 11:34 AM
To: Ivica Bukvic
Cc: Jonathan Wilkes; pd-list@iem.at List; Peter Brinkmann
Subject: Re: [PD] libpd separating gui from core
 
On Mon, Feb 24, 2014 at 12:29 AM, Ivica Bukvic  wrote:
 
>On Sun, Feb 23, 2014 at 11:04 PM, Dan Wilcox  wrote:
> 
>I consider that a sad thing. At least with Pd-extended, it was largely 
>Pd-vanilla + externals.
> 
>I don't think it needs to be sad. Yes, pd-extended is pd-vanilla + externals + 
>most limitations of the vanilla. How does that help you in your mission to 
>move forward?
 
I think you're missing my point here. With Pd-extended, you know you would make 
things which would work with Pd-vanilla if it had the appropriate externals 
compiled and available. With Pd-L2ork, there's a good chance that will not be 
the case as you move forward, thus fragmenting people between the apps. The 
Linux distro analogy is not a very apt one as there are far fewer PD users by 
comparison.
 
But what if breaking things will bring more people in? (I ask this fully 
realizing I am playing a devil’s advocate here since I have no proof of this 
being the case with pd-l2ork nor that this will ever be even remotely close to 
the success of libpd)
 
I'm not saying it *will* happen or that it's your stated goal to split things, 
I'm just trying to suggest again that there could be a middle ground that could 
work for both Miller's and the communities goals. Other projects have managed 
that, why can't ours. Obviously, trying to push all updates and requirements 
back to the source have not worked, but maybe we can decided upon a subset of 
things that could/should be in the core and find a way to implement them. 
Again, I think gui abstraction could be a way to help this.
 
I respect what y'all are doing with Pd-L2ork. It looks really awesome. I also 
know you've been trying to integrate changes back into the Pd-vanilla. I just 
think that there must be another way.
 
I am all ears :-)
 
That said, I would love to entertain the thought of co-developing libpd but I 
think that is currently bogged down by the same predicaments that pd-extended 
and any other non-vanilla implementations have to deal with, which is whether 
you keep the backwards compatibility or move forward as fast as you can at the 
expense of the compatibility.
>> 
>>Which is why I bring up the idea that we find some firmer ground in the bog 
>>and reach a compromise instead of forking galore. If fragmentation is a good 
>>thing, then there really isn't much of a community, simply a few islands 
>>rehashing the same things on a roughly a 5 year cycle. I'm sure you'll keep 
>>PD-L2ork going and it won't go the way of DD, but again there should be a way 
>>to have our cake and eat it too. I don't see the harm in trying.
>> 
>>Also, I'd like to point that, "bogged down" or not, libpd has IMO sparked the 
>>most life into Pure Data over the last few years by bringing lots of new 
>>people in who want to patch for phones and apps embedding libpd. Alot of 
>>those people are Max users ... :D I personally don't like the idea of us 
>>working on libpd when you take off with Pd-L20rk and we might reach a point 
>>where we'd want a libpd-L2ork. Would be nice to have both ...
> 
>A lot of things would be nice but that is not the reality of the current 
>situation. I think backwards compatibility is even less relevant to libpd when 
>it is embedded in ways that are completely transparent to users, but I guess I 
>digress, so I'll shut up.
 
Less relevant? The libpd code is Pd-vanilla. It already works and is backwards 
compatible. This way at least you know that if it works in Pd-vanilla when 
patching it will work in libpd. Should we diverge to make custom changes we 
need and then requ

Re: [PD] libpd separating gui from core

[Jonathan Wilkes]

So let's just take a concrete example: "$@" syntax.  It is a dollarsign 
variable in Pd-l2ork (and maybe in Pd-extended-- can't remember) and it expands 
to the incoming arguments.  In an object box this expands to the arguments of 
the parent.  The code for this feature affects Pd's message parser, which is in 
"the core".  This is just an example-- there is a whole category of features 
which require changes to core code like this one.

If you have a description of a democratic development process that can 
implement such a feature by wrapping Pd Vanilla in a GUI wrapper, document how 
it works, and if it's maintainable I'll help you implement it.

-Jonathan



On Monday, February 24, 2014 1:56 PM, Ivica Ico Bukvic  wrote:
 
 
 
From:Dan Wilcox [mailto:danomat...@gmail.com] 
Sent: Monday, February 24, 2014 11:34 AM
To: Ivica Bukvic
Cc: Jonathan Wilkes; pd-list@iem.at List; Peter Brinkmann
Subject: Re: [PD] libpd separating gui from core
 
On Mon, Feb 24, 2014 at 12:29 AM, Ivica Bukvic  wrote:
 
>On Sun, Feb 23, 2014 at 11:04 PM, Dan Wilcox  wrote:
> 
>I consider that a sad thing. At least with Pd-extended, it was largely 
>Pd-vanilla + externals.
> 
>I don't think it needs to be sad. Yes, pd-extended is pd-vanilla + externals + 
>most limitations of the vanilla. How does that help you in your mission to 
>move forward?
 
I think you're missing my point here. With Pd-extended, you know you would make 
things which would work with Pd-vanilla if it had the appropriate externals 
compiled and available. With Pd-L2ork, there's a good chance that will not be 
the case as you move forward, thus fragmenting people between the apps. The 
Linux distro analogy is not a very apt one as there are far fewer PD users by 
comparison.
 
But what if breaking things will bring more people in? (I ask this fully 
realizing I am playing a devil’s advocate here since I have no proof of this 
being the case with pd-l2ork nor that this will ever be even remotely close to 
the success of libpd)
 
I'm not saying it *will* happen or that it's your stated goal to split things, 
I'm just trying to suggest again that there could be a middle ground that could 
work for both Miller's and the communities goals. Other projects have managed 
that, why can't ours. Obviously, trying to push all updates and requirements 
back to the source have not worked, but maybe we can decided upon a subset of 
things that could/should be in the core and find a way to implement them. 
Again, I think gui abstraction could be a way to help this.
 
I respect what y'all are doing with Pd-L2ork. It looks really awesome. I also 
know you've been trying to integrate changes back into the Pd-vanilla. I just 
think that there must be another way.
 
I am all ears :-)
 
That said, I would love to entertain the thought of co-developing libpd but I 
think that is currently bogged down by the same predicaments that pd-extended 
and any other non-vanilla implementations have to deal with, which is whether 
you keep the backwards compatibility or move forward as fast as you can at the 
expense of the compatibility.
>> 
>>Which is why I bring up the idea that we find some firmer ground in the bog 
>>and reach a compromise instead of forking galore. If fragmentation is a good 
>>thing, then there really isn't much of a community, simply a few islands 
>>rehashing the same things on a roughly a 5 year cycle. I'm sure you'll keep 
>>PD-L2ork going and it won't go the way of DD, but again there should be a way 
>>to have our cake and eat it too. I don't see the harm in trying.
>> 
>>Also, I'd like to point that, "bogged down" or not, libpd has IMO sparked the 
>>most life into Pure Data over the last few years by bringing lots of new 
>>people in who want to patch for phones and apps embedding libpd. Alot of 
>>those people are Max users ... :D I personally don't like the idea of us 
>>working on libpd when you take off with Pd-L20rk and we might reach a point 
>>where we'd want a libpd-L2ork. Would be nice to have both ...
> 
>A lot of things would be nice but that is not the reality of the current 
>situation. I think backwards compatibility is even less relevant to libpd when 
>it is embedded in ways that are completely transparent to users, but I guess I 
>digress, so I'll shut up.
 
Less relevant? The libpd code is Pd-vanilla. It already works and is backwards 
compatible. This way at least you know that if it works in Pd-vanilla when 
patching it will work in libpd. Should we diverge to make custom changes we 
need and then require an entire new gui for people to build patches for libpd 
only? As it is now, libpd development is largely pd development and that's a 
good thing overall. If we can

Re: [PD] libpd separating gui from core

[Jonathan Wilkes]

On 02/23/2014 08:15 PM, Ivica Bukvic wrote:




On Sun, Feb 23, 2014 at 4:40 PM, Dan Wilcox <mailto:danomat...@gmail.com>> wrote:


On Feb 23, 2014, at 3:29 PM, Jonathan Wilkes mailto:jancs...@yahoo.com>> wrote:


Yeah, stuff like that we should be able to solve. I'm not for
ditching the Tcl/Tk gui at all. The work you and Ivica have been
doing seems to be going a long way to fix this. Great! I just
really hope this goes back into vanilla somehow or can be split up
into between libpd and a gui implementation, etc. Otherwise, I
fear a return to DD.


If I may chime in for a sec (pd-l2ork author here), there is 
absolutely no interest in dropping development of pd-l2ork anytime 
soon. Pd-L2Ork already has thousands of lines of code either altered 
or added and I have no intention of slowing down. Likewise, in part 
because I tried in the past, I have no interest in trying to get 
things merged into the core pd. I will very much welcome someone 
else's efforts to do so but knowing Miller's gargantuan goal of 
keeping backwards compatibility, I simply feel this approach is too 
time consuming for me to promote the rate of development I (and as it 
appears many others on this list) desire.


Additionally, DesireData never had any stable releases as far as I 
remember.  matju may have used it for some of his projects, but when I 
played around with it there were major chunks of functionality missing, 
and easy crashes.


If someone wanted to port over DD's keyboard-only patching feature to 
Pd-l2ork, for example, you'd very quickly see the difference between the 
two.  Because once it makes it into a release you'd be using the feature 
in a piece of stable software.  That's an enormous difference.


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

Re: [PD] libpd separating gui from core

[Jonathan Wilkes]

On 02/23/2014 07:37 AM, Dan Wilcox wrote:

On Feb 23, 2014, at 2:11 AM, Jonathan Wilkes  wrote:


Do you have an example of a patch that suffers from Pd's current 
single-threaded implementation that would be measurably improved by using a 
multi-threaded approach?

Ask any of the people who have to run two instances of Pd in order to have both 
GEM and audio without dropouts. And this is in 2014 with modern computers 
orders of magnitude more capable than when Pd was first designed.


This is probably naive, but wouldn't it suffice to have an object that 
does automatically what the user is forced to do manually atm?


Manual -- user opens a Pd instance for GEM and a separate Pd instance 
for audio
Auto -- user creates an object [foo-audio-magic somepatch.pd] which 
automatically fires up a separate instance-- _not_ a child of the 
first-- for the audio.





Also, what is the metric to use here?

Mmm open a larger patch with audio running, momentary dropouts.


How do you know that's due to Pd's single-threadedness, and not some 
CPU-hogging object, or a poorly optimized object chain, or Pd doing GUI 
calculations in the core thread as well as tk's thread?




Also, this is perhaps better to ask a beginner trying to pickup PD after starting with Max MSP, 
they may not give you "meaningful metrics" but their impression may be along the lines of 
"not only does this program look old, but it keeps clicking when I'm dragging things 
around". Etc etc


That particular problem is due directly to *_getrect calls in a patch 
with lots of objects (and possibly a bunch of *_click calls if hovering 
over an object that does a lot of computation in such a function).  It's 
not super easy to solve, but it's approachable because the Pd-GUI 
already exists.  But that's a completely separate issue from getting 
something like GEM to run in its own thread.




Things maybe acceptable to us PD "grey beards", but at some point it would be nice to find a way to 
enter the modern, multicore multithreaded world. Moores law has shifted from clock speed to "just add 
more cores" years ago now, so it's not like "buy a faster machine" is going to magically solve 
single threaded speed issues.


It's not acceptable, but if you want to move forward _and_ do work that 
will be in sync with or accepted into Pd vanilla I don't see a way 
forward.  I can't even get help docs into Pd vanilla, and they were 
written to the PDDP spec that this community came up with and approved.  
And as you know, there's a publicly viewable list of the same exact 
frustrations from all kinds of developers with various styles of 
communication.




At the very least, we should be able to run a performance intensive GEM patch 
with real time audio without drop outs *while* editing.


Did you use any of the Pd-l2ork versions before it moved to Tkpath? It 
didn't solve the *_getrect problem I mentioned above, but it solved a 
whole lot of the problems that cause dropouts while editing, mainly by 
shooting way fewer messages across the socket.


Anyway if you're interested in coding anything up related to this 
thread, I know Ivica is interested in solving the GEM issue you mentioned.


-Jonathan


  Oh wait, that's called Max MSP. :D And that is perhaps the reasonable stance 
taken by a certain teaching institution I just left who is really only 
interested in PD on places where Max currently can't be used, like Raspberry PI.

enohp ym morf tnes
--
Dan Wilcox
danomatika.com
robotcowboy.com



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

Re: [PD] libpd separating gui from core

[Jonathan Wilkes]

I'm just having trouble with the specifics.  Do you have an example of a patch 
that suffers from Pd's current single-threaded implementation that would be 
measurably improved by using a multi-threaded approach?  Also, what is the 
metric to use here?

To compare apples to apples, imagine that every g_* sourcefile has already been 
moved to the GUI side of both the single- and double- threaded designs that are 
being compared.


-Jonathan




On Sunday, February 23, 2014 12:30 AM, Rich E  wrote:
 





On Fri, Feb 21, 2014 at 3:54 AM, Jonathan Wilkes  wrote:

On 02/20/2014 09:50 PM, Rich E wrote:
>
>
>>
>>
>>On Wed, Feb 19, 2014 at 12:07 AM, Jonathan Wilkes  wrote:
>>
>>On 02/18/2014 11:11 PM, Rich E wrote:
>>>
>>>
>>>>
>>>>
>>>>
>>>>
>>>>On Mon, Jan 13, 2014 at 5:35 PM, Dan Wilcox  wrote:
>>>>
>>>>Ah wait, duh. Of course the graph needs to know positioning, that's how it 
>>>>determines execution order or independent blocks of objects right? 
>>>>>
>>>>>
>>>>>On Jan 13, 2014, at 5:14 PM, Dan Wilcox  wrote:
>>>>>
>>>>>Does the dsp graph rely on positioning? I thought only via connections. 
>>>>>I'd imagine the gui wrapper should only worry about positioning and simply 
>>>>>update those changes when saving.
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>IMO a separation between GUI and core could/would include position, e.g. 
>>>>objects have their connections mapped by an index, GUI assigns the index to 
>>>>the object based on position.  This would allow for some much more 
>>>>sophisticated GUI's, such as 3d, or even a more human-readable text version 
>>>>(json has been mentioned).
>>>
You run into problems when you want to get decent GUI interaction _and_ expect 
to deliver audio to the soundcard in realtime.
>>>
>>>
>>
>>
>>The GUI and audio shouldn't be updated from the same thread.  This is one 
>>nice thing about libpd, it forces a separation.
>
What are the drawbacks to the multi-threaded approach?  Specifically, for a 
full-fledged editing environment where you can't easily predict what the 
userbase is going to come up with inside the GUI?
>
>
>

Firstly, I think the decision should at least be available (to process audio 
and GUI on separate threads), since this is the most common way to handle the 
two different update rates.  Especially since, with most GUI frameworks, you 
_must_ update the GUI on the main / UI thread, which is running at 60fps.

But to answer the question... drawback is having to manage the whole 'this 
method must to be called on the audio thread, and that method must be called on 
the non-audio thread'. However this turns out to be little of a limitation 
since it is almost always what you want to do anyway, and you gain huge amounts 
in the area of responsiveness.

In the end, every situation is different. With pd vanilla, audio is most 
important and maybe that deserves the current architecture.  To me, it is more 
about keeping options open, which is why I think abstracting the visual 
position from the core is a good idea.___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] threads in pd, dataflow

[Jonathan Wilkes]

On 02/21/2014 10:04 PM, Simon Wise wrote:

On 22/02/14 06:28, Jonathan Wilkes wrote:

On 02/21/2014 06:41 AM, Simon Wise wrote:



Something to really make pd parallel would involve treating fan-outs as
opportunities for the interpreter to launch each branch in a new 
thread,

implementing the inherent parallelism in the dataflow paradigm (e.g. in
the pd definition of fan-outs as being executed in undefined order). 
Here
the trigger object is used to force sequential execution where 
required,

just as it is now.


Practically speaking, it's completely different for control than for 
signal

domain. For signal domain fanouts there's an understanding that Pd gets
stuff done when it needs to get done. In the control domain, there's 
even a
philosophy of _never_ having fanouts at all. I don't know what the 
effect

would be of trying to auto-parallellize a signal diagram, but I'm pretty
sure trying to auto-parallellize a control diagram wouldn't make much 
of a

dent.


I was referring to parallelising using control fanouts only, but 
didn't make that clear. 'No fanouts, always use triggers' is a very 
sensible policy to avoid easily overlooked bugs when, as in pd, 
fanouts are just an implied trigger with an undefined order.




[...]

Even the dsp<->gui problem would be addressed by a proper dataflow 
implementation if it was done well. Keeping all the gui stuff in 
branches which don't have ~ objects should result in these branches 
being separate threads, and well implemented these would not be 
allowed to block ~ branches.


To know whether a control branch interacts with the signal domain is to 
solve the halting problem, no?


But you could have some kind of "seal" object that verifies the user 
thinks a subpatch or canvas is 100% pure control domain.  And then Pd 
could take that to mean throw it in its own thread (and throw 
warnings/errors if it finds a message going to a signal object, or 
fudging with dsp in any way).


It could look like a wax seal and always be at the top-left of the patch.

-Jonathan

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

[PD] core <-> gui question

[Jonathan Wilkes]

Hi list,
 I've got a nice little method for an info class in Pd-l2ork that 
tells whether an x/y coordinate lies within an object on a particular 
canvas.  For the new svg-style drawing commands I've added, this method 
makes it possible to do some fairly simple tests within a patch to make 
sure I don't break things along the way.  For example, I can check the 
bbox of scalars that contain transformed shapes, or check to make sure 
that the stroke-width is contained within the bbox, check positions of 
gop scalars, nested data structures, etc.


If the gui and core were truly separated, how would I do these tests 
within Pd?  To follow the Pd message-passing model, I need to get an 
answer to my query in zero logical time.  If the bbox data is only held 
by the gui then I have to send a request over the socket, and the object 
chain will have finished computing before the gui sends back its data.  
If the core holds a synced copy of bbox data then the gui must either a) 
constantly bombard it with updated values or b) send a message that 
tells the core what got updated and let the core update data for all 
relevant objects.  In which case there's no longer really a separation 
between gui and core.


On a related note-- for the new drawing commands I'm doing all kinds of 
crazy calculations in the core for stuff like getting the bbox of an svg 
path.  It's ridiculous because all that math has already happened in 
Tkpath, but I can cache it so Pd doesn't take a huge performance hit.  
But I simply couldn't figure out a way to get that data from the gui in 
a way that doesn't cause all kinds of syncronization problems.  By the 
time *_getrect is called the core must already have the bbox data, 
otherwise it's too late.  Is there some way to deal with that without 
moving the entire gui logic out of the core?  I couldn't think of one.


-Jonathan

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

Re: [PD] libpd separating gui from core

[Jonathan Wilkes]

On 02/21/2014 06:41 AM, Simon Wise wrote:

On 21/02/14 20:41, Charles Goyard wrote:

Hi,

just to give some example of single vs multi-threaded, and some
comparison points.

- projects like haproxy and lighthttpd show that good state
machine programming can be more efficient that multi-threaded
programming, even on multi-core computers. BUT they handle a much
reduced number of use cases.

- graphics chipsets are massively parallel. They handle huge amounts of
data. BUT they are hard to build, they also handle a much recuced number
of use cases, CUDA and OpenCL being a generalization.

-  (on windows) has its core single-threaded, and a lot of objects
are multi-threaded, just like pd. It suffers the same than pd: when
you get interactive with the GUI, the framerate slows down dramatically.

- whitecat (a DMX software) has its GUI that runs on OpenGL, and it's
not that efficient.

In the case of PD, maybe just a good mix of libpd and a generalization
of pd~ can improve things much.


[pd~] deals with the particular case of creating an extra dsp thread, 
it incurs overhead to do so and does not isolate the dsp from a busy 
patch. It is quite orthogonal to creating separate gui, video, audio 
or whatever threads.


What I guess you mean is very different .. an object to launch a 
distinct pd process within (and isolated from) the rest of a pd patch. 
But I am not sure how that would be any better or more human-readable 
than 2 pd instances with [netsend]s and a suitable script to launch 
them together.



Something to really make pd parallel would involve treating fan-outs 
as opportunities for the interpreter to launch each branch in a new 
thread, implementing the inherent parallelism in the dataflow paradigm 
(e.g. in the pd definition of fan-outs as being executed in undefined 
order). Here the trigger object is used to force sequential execution 
where required, just as it is now.


Practically speaking, it's completely different for control than for 
signal domain.  For signal domain fanouts there's an understanding that 
Pd gets stuff done when it needs to get done.  In the control domain, 
there's even a philosophy of _never_ having fanouts at all. I don't know 
what the effect would be of trying to auto-parallellize a signal 
diagram, but I'm pretty sure trying to auto-parallellize a control 
diagram wouldn't make much of a dent.


-Jonathan



Simon

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



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

Re: [PD] t_scalar member sc_vec

[Jonathan Wilkes]

On 02/21/2014 09:00 AM, Ivica Bukvic wrote:


Because this way you can reference data points with sc_vec+n as 
opposed to dealing with single or double linked lists (since sc_vec 
can be an array).




If sc_vec is a pointer then you can access data points using the same 
technique, which is pointer math after all.


For everyone's amusement, here's an exercise in my own rank speculation: 
something about a t_word array aligning on boundaries in a way that you 
wouldn't be able to guarantee with a pointer to a t_word.  So if you can 
guarantee there won't be padding you save memory in 1981.


Is it something like that, Miller?

And do scalars actually go back to 1981, or that's just around the time 
you learned the technique?


Also-- this technique means that for sc_vec[1] its position inside the 
struct suddenly become relevant.  That is, if you put sc_template as the 
last member field you'd be indexing into the wrong place when you tried 
to read/write sc_vec data.  Is that right?


-Jonathan

On Feb 21, 2014 7:26 AM, "Charles Goyard" > wrote:


Hi,

Sorry for this question, but why isn't sc_vec a good old pointer ?

> t_gobj sc_gobj; /* header for graphical object */
> t_symbol *sc_template;  /* template name (LATER replace with
pointer) */
> t_word sc_vec[1];   /* indeterminate-length array of
words */
> } t_scalar;
>
> How is a static t_word array of size 1 an indeterminate-length
array?  Is its placement as the last member of the struct required?

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



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


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

Re: [PD] libpd separating gui from core

[Jonathan Wilkes]

On 02/20/2014 09:50 PM, Rich E wrote:



On Wed, Feb 19, 2014 at 12:07 AM, Jonathan Wilkes <mailto:jancs...@yahoo.com>> wrote:


On 02/18/2014 11:11 PM, Rich E wrote:




On Mon, Jan 13, 2014 at 5:35 PM, Dan Wilcox mailto:danomat...@gmail.com>> wrote:

Ah wait, duh. Of course the graph needs to know positioning,
that's how it determines execution order or independent
blocks of objects right?

On Jan 13, 2014, at 5:14 PM, Dan Wilcox mailto:danomat...@gmail.com>> wrote:


Does the dsp graph rely on positioning? I thought only via
connections. I'd imagine the gui wrapper should only worry
about positioning and simply update those changes when saving.




IMO a separation between GUI and core could/would include
position, e.g. objects have their connections mapped by an index,
GUI assigns the index to the object based on position.  This
would allow for some much more sophisticated GUI's, such as 3d,
or even a more human-readable text version (json has been mentioned).


You run into problems when you want to get decent GUI interaction
_and_ expect to deliver audio to the soundcard in realtime.


The GUI and audio shouldn't be updated from the same thread.  This is 
one nice thing about libpd, it forces a separation.


What are the drawbacks to the multi-threaded approach? Specifically, for 
a full-fledged editing environment where you can't easily predict what 
the userbase is going to come up with inside the GUI?




So in this type of world, the GUI can do whatever it needs to do in 
order to draw at the desired framerate, and flags graph changes along 
the way.


In Pd-extended and Vanilla currently there is very little optimization 
to get the most out of Tk.  Those problems have a tendency to get lumped 
in with single-threadedness.  So if someone actually gets something with 
a better design up and running, just remember that you have to do 
similar optimization work before the benefits of the new system really 
start to shine.  Otherwise you'll get burned out when the right approach 
still gets dropouts-- from the odd inefficient algorithm, some 
"standard" widget that eats CPU for lunch, or whatever else isn't 
documented on the shiny frontpage of the toolkit.


-Jonathan

 The changes are then converted into a GUI-agnostic format and 
synchronously issued to the audio context.


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

[PD] t_scalar member sc_vec

[Jonathan Wilkes]

Can anyone explain what's going on with this in m_pd.h:

typedef struct _scalar  /* a graphical object holding data */
{
    t_gobj sc_gobj; /* header for graphical object */
    t_symbol *sc_template;  /* template name (LATER replace with pointer) */
    t_word sc_vec[1];   /* indeterminate-length array of words */
} t_scalar;

How is a static t_word array of size 1 an indeterminate-length array?  Is its 
placement as the last member of the struct required?

I see lots of mysterious casts in the internals of Pd's data structures.  
What's the trick here, and is it documented anywhere on the interwebs, a C 
standard doc, etc.?

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

Re: [PD] libpd separating gui from core

[Jonathan Wilkes]

On 02/18/2014 11:11 PM, Rich E wrote:




On Mon, Jan 13, 2014 at 5:35 PM, Dan Wilcox > wrote:


Ah wait, duh. Of course the graph needs to know positioning,
that's how it determines execution order or independent blocks of
objects right?

On Jan 13, 2014, at 5:14 PM, Dan Wilcox mailto:danomat...@gmail.com>> wrote:


Does the dsp graph rely on positioning? I thought only via
connections. I'd imagine the gui wrapper should only worry about
positioning and simply update those changes when saving.




IMO a separation between GUI and core could/would include position, 
e.g. objects have their connections mapped by an index, GUI assigns 
the index to the object based on position.  This would allow for some 
much more sophisticated GUI's, such as 3d, or even a more 
human-readable text version (json has been mentioned).


You run into problems when you want to get decent GUI interaction _and_ 
expect to deliver audio to the soundcard in realtime.


Actually even in 2d without audio the problems manifest themselves 
pretty quickly.  For example: open the svg tiger inside Inkscape and 
move it around.  Notice the clever trick-- the image is broken into 
tiles and moved starting with the pieces closest to the mouse. Since the 
user's eye focuses on the mouse pointer, the interaction looks snappy 
even though it may take half a second or more to finish moving the tile 
furthest from the pointer.


When you add realtime audio the options are either to err on the side of 
sluggishness or to be responsive and risk dropouts.  If you want it to 
be responsive in both video and audio then you have to start doing some 
serious optimizations based on what you think the user cases are for the 
software.  For example, the Inkscape trick is perfect for creating and 
manipulating vector graphics, but it would be terrible for a 2d 
animation environment where you'd presumably want the tiger to move as a 
single unit.


However, many of Pd's current problems don't have a lot to do with 
that.  Tk is pretty good at being sluggish and avoiding dropouts when it 
doesn't have idle time to do graphics updates.  In fact I can move 
around an svg tiger on a canvas without interrupting the "test audio" 
patch.  Most dropouts related to the GUI have to do with what amounts to 
a DDOS attack from the core to the GUI.  When you flood tcl with data 
from the socket it can't really do anything else but spend time 
receiving it.  When you add that to whatever Pd core is doing to 
generate all those messages in the first place, you probably won't have 
any time left over for delivering audio.


Other toolkits are certainly more efficient than Tk.  But if you're 
dragging an antialiased wire from the top left of the window to the 
bottom-right, the toolkit needs time to do those redraws.


Finally, I'm not really sure how Open-GL and hardware acceleration plays 
into all this. For example, Qt Graphics View docs have a note about 
accelerated graphics possibly adding a performance hit and possibly more 
latency, but it's only in the context of hardware that doesn't do 
floating point computations efficiently.  I played around with Kivy a 
bit, which is hardware accelerated but honestly didn't see much of an 
improvement in cpu usage over comparable stuff in Tkpath.


-Jonathan




cheers,
Rich



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

Re: [PD] libpd separating gui from core

[Jonathan Wilkes]

On 02/18/2014 04:00 AM, IOhannes m zmoelnig wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2014-02-17 22:42, Jonathan Wilkes wrote:

No sane person is going to do incremental work without a plan on
GUI software in 2014 that only has a single undo.

luckily the work on the GUI will most likely happen in git, which
gives you infinite undo.


The question is whether a highly capable dev who isn't already 
entrenched in Pd development would see participation as worthwhile or a 
waste of time.


What I'm saying is that without a clear plan, no sane developer is going 
to undertake the work of adding infinite undo, various GUI improvements, 
or anything else that can't ship as an external.


But yes, technically you can use Git to do yet another GUI rewrite if 
you wish.


-Jonathan



fmasdr
IOhannes
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJTAyE4AAoJELZQGcR/ejb4p20P/0v4ZnEhRhzuLBzl3Jr8bGRC
FSp04pTFlgdIqYPvJJooQA2vWJPHCOcHNPI7u8kDJk3tr+1p1EQ41apK6qFw/xU5
E1093htLiZojq2OCMMO9ZOYbm0DXZZHRmo6nMcG2GXceqCSNA3OMw7p4MRGyVJB1
tS/gyckHowInGDif+3eYKSD6iTZcBFpa/QahaT9kZzTk6HQ4hRtoro5OZ/z97nj6
ILJsDv0xK01I4MF1s9OUsMdVp6itTCI9irHYOMr1IeNbhQMaZrT1z2HtqG9q8NZs
Q4p6uKGtGgqIZU5noCrmLnxVde0HlirpxSIDzq+FHJ4b9dQk9pJSI+zKTE8hCs1O
sCUFZNi2udd9NwkaAqs1/2msf15WO+GmguMZXzaOiOxcx9FKrVE03IATZ4vqLNCd
AucU9dxohcYrqPuzzBhfxmmYk6aLwPaZpamezTeBNCni0qn25X5ZwDWY6YHnd5fO
Ck1yvhWKO0g5jVH2Tx4iAgnceKVqe++q5q+XnR8goFPFvxPC3THCGoGaIx4FSgea
Zcfy3VymCWByyG57K2yV2R+wr3qwK8TDligtM0XoUB+a0caYr6uq5qMnOTzOJpIt
GpwrWerw1957a/ccxpkNpofh4HPosg0oeYRajc1mELY07bLcahgMaIGxIevxvub2
00RL1CEc36ySA5xLzcsd
=M/8o
-END PGP SIGNATURE-

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



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

Re: [PD] libpd separating gui from core

[Jonathan Wilkes]

On 02/17/2014 10:48 AM, Hans-Christoph Steiner wrote:

I think that the way forward with the pd/gui separation is to work on the low 
hanging fruit, things that are easy to fix.  Let the hard parts for later, 
which will only be a couple areas.

So that means looking at everywhere where sys_gui() or sys_vgui() is called, 
and seeing how the raw Tcl in those calls can be converted into Tcl procs.  The 
syntax for calling Tcl procs is very close to a Pd list, so that is an easy way 
to get close.

The Pd dev community has always been plagued with a desire for grand plans 
before starting work.  And that has proven to mean nothing happens.


No sane person is going to do incremental work without a plan on GUI 
software in 2014 that only has a single undo.


-Jonathan



.hc

On 13/01/2014 15:32, Dan Wilcox wrote:

As Hans has proposed for years, IMO this is really the only way to
perhaps solve the "PD gui development doesn't move fast enough" problem
in the long term. In this case, Miller would have the core (in libpd) &
the pd-vanilla wrapper gui formally separated while everyone else can
then use the same libpd core within other flavors. The DSP core is the
heart and soul and I see no reason to try and change that in any way.


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





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

Re: [PD] Wich licence?

[Jonathan Wilkes]

On 02/15/2014 03:14 PM, olm-e wrote:

On 15/02/14 20:53, pd-list-requ...@iem.at wrote:

Date: Sat, 15 Feb 2014 16:52:58 -0300
From: Mario Mey 
Subject: Re: [PD] Wich licence?
To: pd-list@iem.at
Message-ID: <52ffc59a.4030...@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 14/02/14 15:45, Jonathan Wilkes wrote:

How would that be any different than spyware?

-Jonathan

Haha! Good point!

Thanks everybody for the answers. I took a look to Matt Davey's DIY2
effects and he put no license txt file on its folder. Maelstorm mmb
libraries have no license too...

My patch is for everyone who wants to use it or learn with it. If
someone finally uses MEH-SYSTEM or a modified version of it in stage or
for a video or whatever... I "would like" to know it... only that!

Maybe I leave it as is. Saying nothing about license...


Skim the Wikipedia pages for GPL and 3-clause BSD, choose the one you 
prefer, and then you're done.


Otherwise you create potential work for anyone who may have a use for 
your software to figure out what the terms of use and distribution are.  
It's probably not a big deal for a particular piece of software, and 
there are plenty of Pd patches out there that don't specify anything.  
But when you take, say, everything that exists on Github, the lack of 
licenses probably leads to busywork that eats up measurable amounts of 
time and effort.


-Jonathan





--

Hello,
having no licence is probably not a good idea, as it's like enforcing
the default copyright rules that basically give no rights at all ...
(lots of code are practically not legaly usable on github for that
reason f.ex.)
the best would be IMHO to put it in (L)GPL and gently ask to downloaders
to report use as a courtesy on the download page...
have a good day,

Ol.

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




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

Re: [PD] Wich licence?

[Jonathan Wilkes]

On 02/14/2014 08:16 AM, Mario Mey wrote:
I made a Multi-FX Looper called "MEH-SYSTEM", posted in PD Forum: 
http://puredata.hurleur.com/viewtopic.php?pid=37430


I want to put a license to it. Where should I get information about 
types of licences?


I don't think in any restriction... I only would want to know where, 
when, how and by-who it was used. Only that.


How would that be any different than spyware?

-Jonathan



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





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

Re: [PD] increasing zone of inlet / outlet

[Jonathan Wilkes]

On 02/13/2014 10:27 PM, Ivica Bukvic wrote:


In pd-l2ork nlets are highlighted which makes them grow and as a 
result you can pinpoint them more easily. In k12 learning mode they 
are even bigger to help kids select them. HTH




That's after you register a "hit".  But can you actually register a 
"hit" when the mouse is within n pixels of the xlet?


I ran into this with the svg-data structures stuff.  I made some points 
on a graph grow when the mouse enters them.  But it turns out it's much 
more usable if you have an insible area larger than the point to 
register an "enter" event and then grow the point to that size.


-Jonathan

On Feb 13, 2014 5:23 PM, "Jonathan Wilkes" <mailto:jancs...@yahoo.com>> wrote:


You'd have to tweak the stuff in g_text.c and probably also
g_rtext.c to lie about the rectangle size, and to enlarge the bbox
for what gets counted as an xlet, then recompile.

Meanwhile, there's a single tk canvas subcommand called
"-closeenough" that does exactly what you want.  But Pd doesn't
use that-- it only fowards mouse motion over the socket to Pd. 
Then Pd core queries the bounding box of every object on the

canvas, to see whether it falls within the mouse coordinates.  It
does this for _every_ single "motion" message received from the
gui.  (Run pd with the -d 3 flag to see how often these messages
get sent.)

-Jonathan


On Thursday, February 13, 2014 4:30 PM, "pured...@11h11.com
<mailto:pured...@11h11.com>" mailto:pured...@11h11.com>> wrote:
Hi all,

I am getting older and it's more and more difficult to click right on
the inlet or outlet. How to change increase the zone around them?
I am
using PD-0.43.4-extended.

Thanks

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



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



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

Re: [PD] increasing zone of inlet / outlet

[Jonathan Wilkes]

You'd have to tweak the stuff in g_text.c and probably also g_rtext.c to lie 
about the rectangle size, and to enlarge the bbox for what gets counted as an 
xlet, then recompile.

Meanwhile, there's a single tk canvas subcommand called "-closeenough" that 
does exactly what you want.  But Pd doesn't use that-- it only fowards mouse 
motion over the socket to Pd.  Then Pd core queries the bounding box of every 
object on the canvas, to see whether it falls within the mouse coordinates.  It 
does this for _every_ single "motion" message received from the gui.  (Run pd 
with the -d 3 flag to see how often these messages get sent.)

-Jonathan




On Thursday, February 13, 2014 4:30 PM, "pured...@11h11.com" 
 wrote:
 
Hi all,

I am getting older and it's more and more difficult to click right on  
the inlet or outlet. How to change increase the zone around them? I am  
using PD-0.43.4-extended.

Thanks

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

Re: [PD] Infinite Permissions Loop

[Jonathan Wilkes]

On 02/10/2014 05:43 PM, Wesley Boynton wrote:
No such luck, unfortunately. All pd-related programs have the 
necessary permissions, yet I am still stuck in the loop.


Thanks a bundle,
~W


On Mon, Feb 10, 2014 at 5:37 PM, Simon Wise > wrote:


On 11/02/14 08:24, Wesley Boynton wrote:

Hello, all! I am currently using PD-Extended in both OSX 10.8
and 10.9
environments.

On our administrator accounts, we installed X11 and everything
went fine.
It launches and all is well.

However, in our primary user accounts, we're greeted with a
"You don't have
permission to use the application 'Pd-extended'" dialog.
Repeatedly. No
matter how many times I grant it permission on an always or
one-off basis,
it continues to pop up the same dialog until I surrender and
click "OK."



I don't understand-- if you surrender by clicking "Ok" to the dialog 
then where is the infinite loop?


Does the main Pd console window come up?

-Jonathan



This is, by the way, all despite the fact that PD and X11 are
on the list
of Parental Control-Approved applications for use.

Any input would be extremely appreciated and valuable.


maybe you need Wish and/or Pd-extended and/or pd-gui or something
on that "safe" list as well?


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




--
~Wesley Boynton
http://www.wesleyboynton.com
CELL: 703-635-0839


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


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

Re: [PD] Is open source better?

[Jonathan Wilkes]

On 02/10/2014 05:31 PM, Simon Wise wrote:

On 11/02/14 04:40, Jonathan Wilkes wrote:


Unfortunately the open source definition was designed to subtly hide the
ethical reasons for doing open source development.  The reasoning for 
this

was quite straightforward-- "share with your neighbor" doesn't attract
business dollars.  So open source advocates focus on efficiency, like 
the
ability to plug a 3-clause BSD-licensed library into just about any 
device
you want, even a device that is locked down and requires the final 
app to be

proprietary.


If you consider attracting business dollars actually spent on ongoing 
development of open source code then the GPL, explicitly stating its 
aims and with strict copyleft terms has been quite successful (not 
denying that BSD, Apache and similar have also, in many cases) 


That's true, but an open source advocate could still reframe that in 
terms of efficiency, cost-savings, etc., rather than freedom for the end 
user.  An open source advocate could even make the argument that the GPL 
actually gets in the way even for the most successful projects that are 
licensed with it, creating unnecessary bureaucracy and copyright 
sign-off requirements in what would otherwise be a post-license digital 
utopia.


I don't buy those arguments, but the point is that if there are enough 
voices framing everything in those terms then fundamental principles 
about user freedom get lost.  I mean, if I'd never heard much about 
freedom of the press then who knows if I'd find it reasonable to 
prosecute journalists who receive classified information and "sell" it 
to their publishers in the form of news. Instead, that sounds like 
tyranny to me.  And that's more likely due to a long line of teachers 
with the integrity to explain those principles than to living in a 
country licensed under the Constitution. :)


-Jonathan



If anyone wants to read a principled statement on user freedom, it's 
here:

http://www.gnu.org/philosophy/free-sw.html

-Jonathan


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





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

Re: [PD] Is open source better?

[Jonathan Wilkes]

To answer your last question: have a look at webpd:
https://github.com/sebpiq/WebPd

There's a simple demo patch here:
http://sebpiq.github.io/WebPd/sound-check/sound-check.html

That's Pd's basic audio engine and message passing system running in 
javascript.  So in terms of open source, the efficiency is undeniable.  To run 
Max/MSP in a web page, they'd have to figure out some complex way to protect 
their proprietary code while still making it possible to make sounds by adding 
a script in the html.  The only practical thing I could think of is running a 
centralized service, but again that costs money and maintenance where a 
decentralized lib like webpd runs on the user's device.

Addressing the oddity of using proprietary software (IOS) to point out the 
benefits of open source:

Unfortunately the open source definition was designed to subtly hide the 
ethical reasons for doing open source development.  The reasoning for this was 
quite straightforward-- "share with your neighbor" doesn't attract business 
dollars.  So open source advocates focus on efficiency, like the ability to 
plug a 3-clause BSD-licensed library into just about any device you want, even 
a device that is locked down and requires the final app to be proprietary.

This is equivalent to teaching the scientific method, but downplaying the 
importance of reproducibility for some seemingly practical purpose.  If enough 
scientists are weak on such a fundamental aspect of their job due to bad 
education it will degrade their ability to carry out meaningful, reproducible 
experiments.

So open source advocates can't have it both ways.  If they purposely exclude 
the golden rule and "user freedom" from their marketing materials because it's 
such a drag, I don't see how they can complain when the efficiency of their dev 
model takes users and business to places the initiative didn't want them to end 
up.  Whether it's Google's centralized services or Apple and Android 
smartphones that spy on the user, you can't fight back if you aren't willing to 
state the fundamental principle that users must be free to determine how the 
devices they own actually operate.

If anyone wants to read a principled statement on user freedom, it's here:
http://www.gnu.org/philosophy/free-sw.html

-Jonathan




On Sunday, February 9, 2014 9:24 PM, Simon Wise  wrote:
 
On 10/02/14 11:53, Pall Thayer wrote:
> I'm giving a presentation this week. In a way, it's a counter argument to a
> recent presentation on Max/MSP. One of the things that I want to highlight
> is the "open sourceness" of PD. libpd presents a very good argument and
> I'll be highlighting a project I was involved with that produced an IOS app
> that used libpd as the audio engine. Is there anything else I should be
> considering besides the obvious points of open source being open source.
> Concrete examples of PD's open sourceness trumping proprietary technologies?

IOs is an odd choice for talking about open source when the only way to install 
such an app in a device (without jailbreaking it or paying the developer tithe) 
is by licensing the binary closed source (on their terms) to Apple to 
distribute 
via their platform-monopoly app store, which will not distribute the sources or 
GPL or LGPL apps?

Certainly licenses such as libpd's BSD like one do allow reuse of the code in 
any app, open source or otherwise, but then is that use still open source???


Simon

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

Re: [PD] How to get a list of midi devices without GUI

[Jonathan Wilkes]

In Pd-l2ork you can also do this:
[print(
|
[pdinfo]

Which prints all the info for the running Pd instance to the console, including 
devices.  Or you can send it a message to get a specific attribute like
[audio-outdev, midi-outdevlist(
|
[pdinfo]

I tried it with [loadbang] and -nogui, and all the audio devices display 
properly.  I can't test midi because I don't have any midi devices.


-Jonathan




On Sunday, February 9, 2014 10:49 AM, Antoine Villeret 
 wrote:
 
hello again, 


I found the issue, 

with `-nogui`, the patch is loaded before midisettings are done (like 
audiosettings)
and `[mediasettings/midisettings]` updates it's own device list on startup or 
on `[device ...(` message.

So when the patch is loaded at startup without gui, 
`[mediasettings/midisettings(` records 0 mididevices.
I have to send a dummy `[device ...(` message 1sec after loadbang to update the 
list and then `[listdevices(` report the right number of devices.
Another solution could be to delay the patch loading.

Shouldn't `[mediasettings/midisettings]` update it's own device lists on 
`[listdevices(` message ?

+
A




--
do it yourself                       
http://antoine.villeret.free.fr



2014-02-09 16:17 GMT+01:00 Antoine Villeret :

thanks, but no, 
>
>
>at least with Pd Vanilla 0.45-4, the right flag is *-listdev* to list all 
>devices (both midi and alsa) in the PD's console.
>
>
>According to this 10-years old post [1], I can still make a redirection of 
>stderr or read at it.
>
>
>Another solution, since my problem concern only Linux, is to read the output 
>of `ls /dev/midi* | wc -l` to get a list of mididevices, but this doesn't tell 
>if it's input or output.
>
>
>+
>a
>
>
>[1] : http://lists.puredata.info/pipermail/pd-list/2004-10/023368.html
>
>
>--
>do it yourself                       
>http://antoine.villeret.free.fr
>
>
>
>2014-02-09 16:08 GMT+01:00 Pagano, Patrick :
>
>
>I think it's just --listdevices on the command line
>>
>>Sent from my iPhone
>>
>>On Feb 9, 2014, at 10:03 AM, "Antoine Villeret"  
>>wrote:
>>
>>
>>Hello,  
>>>
>>>
>>>I'm wondering how to get a list of midiout devices without GUI.
>>>This has to work without GUI.
>>>
>>>
>>>I tried [mediasettings/midisettings] but it always report 0 devices (both in 
>>>and out) when there is no GUI.
>>>i also know the -listdev option to Pd, but this only list devices in 
>>>console, and I need to proccess the number in the patch.
>>>
>>>
>>>I observe this on Linux (both Ubuntu 12.04 64bit and Raspbian (kernel 
>>>3.10.25+) with pd 0.45-4.
>>>But it seems to be OK on MacOS with pd 0.45-3.
>>>
>>>
>>>Thanks
>>>
>>>
>>>Antoine
>>>
>>>
>>>--
>>>do it yourself                       
>>>http://antoine.villeret.free.fr
>>>
>>___
>>>Pd-list@iem.at mailing list
>>>UNSUBSCRIBE and account-management -> 
>>>http://lists.puredata.info/listinfo/pd-list
>>>
>


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

Re: [PD] check mail with pd ?

[Jonathan Wilkes]

On 02/08/2014 11:44 PM, Simon Wise wrote:

On 09/02/14 07:59, Jonathan Wilkes wrote:

On 02/08/2014 01:40 PM, Martin Peach wrote:
A few years ago I implemented a patch for strings in Pd that adds a 
string or
blob type that allows (I think) for what you are describing. I 
believe it's

still part of Pd extended, but Miller didn't like it for some reason.


...

I prefer to manipulate strings in a another language as it just 
seems like a
lot of work to make it happen with boxes and wires when you can just 
call

string functions in a high level language.


...


Kind of like building a Turing machine holes-in-paper-tape version of a
program, it can be an interesting exercise but practically it's 
useless.


Read in transcript of congressional testimony on NSA surveillance.
Split into one string for each line.
Read one line every second.
If a line contains the word "terrorism" make a sound.
User takes a drink.

Totally useful. :)

What is it about boxes connected with lines that you think makes this 
difficult?


Perhaps it is the long term and very well established resistance to 
adding a few types to the message syntax ... integers capable of 
indexing reasonable file lengths, strings which don't flood the symbol 
table, floats that aren't in danger of being truncated, bytes or chars 
which won't trigger parsing issues. Matrices are available  via an 
external library (gridflow, within its own externals including 
non-native print and so forth) and GPU video access is possible via 
GEM with its private message syntax, but core Pd is very focussed on 
what it originally set out to do. There have been some moves on this, 
just very slow and careful ones.


A graphical dataflow language is very nice for dealing with DSP and 
with control and interaction logic, and for doing so in a bunch of 
machines distributed over a network. Pd has lots of good ways to 
receive and send control messages and link with hardware and other 
programs. But dataflow and procedural algorithms are quite different 
and parsing strings is a very common thing to do when programming ... 
if you are familiar with the procedural way and have a good set of 
tools available to abstract the details then its easier to just go 
with what you know.


It would be nice to be able to do this natively, especially since many 
Pd programmers are not that familiar with procedural programming. It 
is certainly practical and worthwhile to extend Pd for this but that 
requires some of the things that have been long put off till later for 
a very very long time. Meanwhile the Lua external provides the way to 
do what remains problematic natively (as much due to policy as 
anything else) and anyone capable of adding functionality to Pd will 
find it much much easier to use Lau than to engage in a huge and 
perhaps fruitless effort to push it into Pd.


It sounds like you are rationalizing and encouraging non-development.

But it also sounds like we agree that there is nothing about boxes of 
text connected with lines that makes string manipulation more difficult 
than lines of text.


-Jonathan



Simon

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






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

Re: [PD] check mail with pd ?

[Jonathan Wilkes]

On 02/08/2014 01:40 PM, Martin Peach wrote:
A few years ago I implemented a patch for strings in Pd that adds a 
string or blob type that allows (I think) for what you are describing. 
I believe it's still part of Pd extended, but Miller didn't like it 
for some reason.


It looks more like a prototype for a string implementation.  I'm not 
even able to do this:


[bng]
|
[str hello_world]
|
[print]

Additionally, moving the cord-inspector over the wire connecting 
displays nothing.  Those are just the first two things I tried to do as 
a user, to view a core atom type which most of the time will be holding 
readable text.


It may seem trivial to get those two things to work, but the point is 
that someone has to do it, for every single internal and external class 
which already understands and can manipulate the one string atom but 
doesn't understand the better string atom.


[str hello 32 world] isn't much fun, either.  But it's hard to improve 
that without the ability for the object box to leave the user input 
unparsed.


I prefer to manipulate strings in a another language as it just seems 
like a lot of work to make it happen with boxes and wires when you can 
just call string functions in a high level language.


I don't understand this.  If you take nearly every string manipulation I 
did in tcl for the search-plugin and put it in Pd, you are either a) 
unrolling several commands in nested square brackets and laying them out 
vertically (or inside an abstraction) or b) putting a tcl line of code 
in a box and connecting its output to the next line of tcl code in a box 
with a wire.  If "a" is troublesome to patch and read in Pd then it was 
hard to write and read in tcl.


There are of course way more complex examples of string manipulation, 
but Pd's tools don't have to be perfect to be useful.


Kind of like building a Turing machine holes-in-paper-tape version of 
a program, it can be an interesting exercise but practically it's 
useless.


Read in transcript of congressional testimony on NSA surveillance.
Split into one string for each line.
Read one line every second.
If a line contains the word "terrorism" make a sound.
User takes a drink.

Totally useful. :)

What is it about boxes connected with lines that you think makes this 
difficult?


-Jonathan



Martin

On 2014-02-08 03:14, Jonathan Wilkes wrote:

On 02/08/2014 01:26 AM, Martin Peach wrote:

You can manipulate strings in pdlua and only export the symbols you
want; yes you need to learn lua but it's not very hard.


That's good practical advice for getting work done with strings atm. But
it's irrelevant to getting decent string manipulation within Pd, meaning
using boxes connected with wires.

The reason for wanting to do string manipulation within Pd is just as
obvious as the question that I didn't have to ask and which you
addressed after your semicolon.

-Jonathan



Martin

On 2014-02-08 01:10, Jonathan Wilkes wrote:

On 02/06/2014 01:53 AM, Chris McCormick wrote:

On 06/02/14 06:29, pured...@11h11.com wrote:

but pd is not really good with strings afaik

Maybe soon:

https://sourceforge.net/p/pure-data/pure-data/ci/8a02332a5fb68edc2899e2f13513c77f0796d21b/ 





https://sourceforge.net/p/pure-data/pure-data/ci/49ffcf8ba5cdde7660e82f1e190fcee7c6fa5627/ 





:)


One of the reasons (I think) the string manipulation libs in Pd 
extended

haven't caught on is because they seem to force users to care directly
about character codes.  If I want to pass the string "hello{world}"
around in Pd, I should not have to know the codes for curly braces 
just

to create that string in an object box.

To work, this will require a new set of GUI classes that allow the 
user
to type strings that get saved underneath as character codes, as 
well as
display lists of character codes as a string in the patch. I don't 
know

any externals that do this, but it shouldn't be hard if you're sending
the text to the GUI as floats.  Also, you need i/o classes to read 
from

and write to files without having to pass through lists of symbols and
floats as intermediaries. Otherwise, you will lose data on the read.
Finally, you can't leverage any of the extant symbol manipulation 
tools,

because then you run into symbol-table growth, dollsym
substitutions/escapes, and all the other problems that I assume are 
the
reason for introducing lists of character codes.  Otherwise you're 
just
pushing the current problems users have with symbols to the edges 
of the

new string library.

I understand the desire for this approach, and it's probably less work
than making symbols deallocatable.  But if the user has to stare at
character codes just to get around the limitations of symbol atoms,
they'll probably just use symbol atoms and work within Pd's current
limitations for string processing.

-Jonathan

Re: [PD] cryptocurrency and pd

[Jonathan Wilkes]

I would be a little cautious about this.  If you ended up implementing 
something that garnered wider interest, you'd raise the reward for attacks on 
normal Pd users and on Pd community infrastructure.  That'd be a major burden 
for Pd users-- keeping an eye out for me.grimm@blah vs me.grim@blah, running 
patches in a virtual machine, having to learn GPG...

That last one makes me shudder.

-Jonathan




On Saturday, February 8, 2014 10:38 AM, me.grimm  wrote:
 
maybe our own "Pdcoin" w/ mining ability only through/with Pd externals/patches

m




On Thu, Feb 6, 2014 at 4:09 AM, i go bananas  wrote:

Has anything been done to try to marry these together yet?  
>___
>Pd-list@iem.at mailing list
>UNSUBSCRIBE and account-management -> 
>http://lists.puredata.info/listinfo/pd-list
>
>


-- 

m.e.grimm | m.f.a | ed.m.
megr...@gmail.com
_ 
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] check mail with pd ?

[Jonathan Wilkes]

On 02/08/2014 01:26 AM, Martin Peach wrote:
You can manipulate strings in pdlua and only export the symbols you 
want; yes you need to learn lua but it's not very hard.


That's good practical advice for getting work done with strings atm.  
But it's irrelevant to getting decent string manipulation within Pd, 
meaning using boxes connected with wires.


The reason for wanting to do string manipulation within Pd is just as 
obvious as the question that I didn't have to ask and which you 
addressed after your semicolon.


-Jonathan



Martin

On 2014-02-08 01:10, Jonathan Wilkes wrote:

On 02/06/2014 01:53 AM, Chris McCormick wrote:

On 06/02/14 06:29, pured...@11h11.com wrote:

but pd is not really good with strings afaik

Maybe soon:

https://sourceforge.net/p/pure-data/pure-data/ci/8a02332a5fb68edc2899e2f13513c77f0796d21b/ 




https://sourceforge.net/p/pure-data/pure-data/ci/49ffcf8ba5cdde7660e82f1e190fcee7c6fa5627/ 




:)


One of the reasons (I think) the string manipulation libs in Pd extended
haven't caught on is because they seem to force users to care directly
about character codes.  If I want to pass the string "hello{world}"
around in Pd, I should not have to know the codes for curly braces just
to create that string in an object box.

To work, this will require a new set of GUI classes that allow the user
to type strings that get saved underneath as character codes, as well as
display lists of character codes as a string in the patch.  I don't know
any externals that do this, but it shouldn't be hard if you're sending
the text to the GUI as floats.  Also, you need i/o classes to read from
and write to files without having to pass through lists of symbols and
floats as intermediaries. Otherwise, you will lose data on the read.
Finally, you can't leverage any of the extant symbol manipulation tools,
because then you run into symbol-table growth, dollsym
substitutions/escapes, and all the other problems that I assume are the
reason for introducing lists of character codes.  Otherwise you're just
pushing the current problems users have with symbols to the edges of the
new string library.

I understand the desire for this approach, and it's probably less work
than making symbols deallocatable.  But if the user has to stare at
character codes just to get around the limitations of symbol atoms,
they'll probably just use symbol atoms and work within Pd's current
limitations for string processing.

-Jonathan


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





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





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

Re: [PD] check mail with pd ?

[Jonathan Wilkes]

On 02/06/2014 01:53 AM, Chris McCormick wrote:

On 06/02/14 06:29, pured...@11h11.com wrote:

but pd is not really good with strings afaik

Maybe soon:

https://sourceforge.net/p/pure-data/pure-data/ci/8a02332a5fb68edc2899e2f13513c77f0796d21b/

https://sourceforge.net/p/pure-data/pure-data/ci/49ffcf8ba5cdde7660e82f1e190fcee7c6fa5627/

:)


One of the reasons (I think) the string manipulation libs in Pd extended 
haven't caught on is because they seem to force users to care directly 
about character codes.  If I want to pass the string "hello{world}" 
around in Pd, I should not have to know the codes for curly braces just 
to create that string in an object box.


To work, this will require a new set of GUI classes that allow the user 
to type strings that get saved underneath as character codes, as well as 
display lists of character codes as a string in the patch.  I don't know 
any externals that do this, but it shouldn't be hard if you're sending 
the text to the GUI as floats.  Also, you need i/o classes to read from 
and write to files without having to pass through lists of symbols and 
floats as intermediaries. Otherwise, you will lose data on the read.  
Finally, you can't leverage any of the extant symbol manipulation tools, 
because then you run into symbol-table growth, dollsym 
substitutions/escapes, and all the other problems that I assume are the 
reason for introducing lists of character codes.  Otherwise you're just 
pushing the current problems users have with symbols to the edges of the 
new string library.


I understand the desire for this approach, and it's probably less work 
than making symbols deallocatable.  But if the user has to stare at 
character codes just to get around the limitations of symbol atoms, 
they'll probably just use symbol atoms and work within Pd's current 
limitations for string processing.


-Jonathan


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

Re: [PD] cryptocurrency and pd

[Jonathan Wilkes]

Pd or otherwise, I'd be very careful about sending any messages back and forth 
with the actual Bitcoin network.  By doing so you are essentially telling the 
internet that fungible, irreversible tokens might exist on your machine, the 
value of which could far exceed anything that you have ever or will ever store 
on your computer.

Also, blockchain.info likes to store the IP of the first node that told it 
about a transaction.  It's pretty well connected, so if you make a transaction 
from your machine your IP is very likely associated forever with that 
transaction.  (Just one of many ways in which Bitcoin is not anonymous.)

But of course if you happen to be in Sochi then everything of value on your 
machine has already been stolen, so knock yourself out. :)

-Jonathan




On Thursday, February 6, 2014 5:59 PM, Thomas Mayer  wrote:
 
On 06.02.2014 10:09, i go bananas wrote:
> Has anything been done to try to marry these together yet?  

PuREST JSON includes a sonification for Bitcoin values going back to
2011, but I guess, that is not what you wanted to know.

Thanks,
Thomas
-- 
"We left all that stuff out. If there's an error, we have this
routine called panic, and when it is called, the machine crashes,
and you holler down the hall, 'Hey, reboot it.'" (Dennis Ritchie)
http://www.residuum.org/

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

Re: [PD] cryptocurrency and pd

[Jonathan Wilkes]

On 02/06/2014 02:08 PM, Charles Goyard wrote:

Hi,

i go bananas wrote:

In what way?

that's what i want to know!

If that's a general question, then the answer is yes, as you can get and
send bytes over a network and do math with pd. It's also the answer for
all general questions like "can I do something a computer does with
pd ?"

It does not mean it fits you needs, or the amount of work you want to
put in :).

Not giving contexts does not lead to useful answers.


That's a self-fulfilling prophecy.

It also turns out to be wrong, because I made another self-fulfilling 
prophecy which turns out to be useful.


-Jonathan



So, do you have something in mind ?


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





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

Re: [PD] cryptocurrency and pd

[Jonathan Wilkes]

On 02/06/2014 11:03 AM, i go bananas wrote:

>In what way?

that's what i want to know!


I don't know the specifics, but I think both cryptography and finance 
are areas where the feature of "everything is a float" actually gets in 
the way.  In either case you cannot afford to lose precision.


But you can prototype some of the features of a cryptocurrency in Pd.  
For example, Bitcoin uses the hashcash algorithm to verify each block of 
the transaction database.  (If I understand it correctly it's like 
brute-forcing SHA256 keys, although they never completely succeed.)  The 
miners basically start a counter, do a mathematical function on the 
value plus the previous value from the last entry in the transaction 
database, and finally check if the output has a certain number of 
leading zeros.


If you ignore for the moment the counter and the mathematical function, 
you can see how the process works.  Attached is a patch that just keeps 
spitting out pseudo-random numbers between 0 and 1 until all of the 
[random] objects happen to output zeros.  It's essentially like a slot 
machine that keeps playing until you win. Now notice that when you hook 
up another [random] to the chain you double the average time it takes to 
find a "winner".  Add enough [random] objects to the chain and you will 
quickly hit a point where you can't compute a "winner" at all (even if 
you change the patch to compute answers as fast as possible).


Bitcoin's "block difficulty" uses the same principle.  The software has 
a hardcoded rule that it should take 10 minutes to find a "winner".  But 
instead of using a bunch of binary values, it uses a single number and 
requires the "winner" to be below a certain value (which is equivalent 
to counting the leading zeros in the representation of the number).  
Over a certain number of days it measures the average time it takes the 
network to compute a "winner".  If it's way less than 10 minutes on 
average then the software automatically does the equivalent of adding a 
[random] to the patch to make it twice as hard.  If it takes too long 
then the software removes a [random].  The actual algo is probably more 
sophisticated but that's what it boils down to.


Now, let's say you hook up 50 [random] objects in that patch and happen 
to find a "winner".  That'd be pretty spectacular, but how do you 
convince everyone that you are being truthful about your claim? This is 
where the hashing function and the counter come into play. Instead of 
the attached patch, imagine a [hash] abstraction that takes a counter 
value in the left inlet and the previous transaction hash in the right 
inlet.  It will output a seemingly unrelated number in response to the 
input, but that number will be unique to the input you give it (or so 
close to unique that we can just call it unique).  That's what a hashing 
function does.  So you essentially do the same thing you did above, 
except you're looking for leading zeros in a single number rather than 
the collective output of a bunch of [random] objects.


When you hit a "winner" you then broadcast your counter value and the 
new transactions to the rest of the network to add to the database.  The 
rest of the network already has the previous entries in the transaction 
database, so they can take those with your counter value and verify that 
the resulting hash actually has the correct number of leading zeros.  
Then everyone starts working on the next "winner".  And why do they do 
that instead of trying to lie and say they were the one that actually 
found the "winner"?  Because the first new transaction in the database 
is the real winner giving 50 bitcoins to themselves, and that 
transaction uses public key cryptography to ensure that it can't be 
forged or changed.


One last thing-- the hashing function is designed so that it's extremely 
difficult (read: impossible) to start with a hash value that has the 
required number of leading zeros and work backwards to figure out the 
right counter value.  Like a slot machine, you have to just keep trying 
until win.  And just like a slot machine, if someone can figure out how 
get a winner without putting in the same work/money everybody else does, 
then the entire system breaks down.


-Jonathan
#N canvas -9 19 708 498 10;
#X obj 176 44 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0
1;
#X obj 176 65 metro 50;
#X obj 176 172 random 2;
#X obj 178 218 +;
#X obj 246 172 random 2;
#X obj 316 172 random 2;
#X obj 178 255 +;
#X obj 178 446 moses 1;
#X obj 46 99 t a;
#X obj 386 172 random 2;
#X obj 178 286 +;
#X obj 456 172 random 2;
#X obj 526 172 random 2;
#X obj 176 86 t b b b b b b b;
#X obj 596 172 random 2;
#X obj 178 327 +;
#X obj 178 368 +;
#X obj 178 413 +;
#X text 356 114 connect more to increase the difficulty;
#X text 358 271 ... and connect them here \, too;
#X obj 46 137 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1
-1;
#X connect 0 0 1 0;
#X connect 1 0 13 0;
#X connect 2 0 3 0;
#X

Re: [PD] cryptocurrency and pd

[Jonathan Wilkes]

In what way?

You should theoretically be able to visualize a proof-of-work block-chain as a 
dataflow diagram, for example.  But generally speaking, Pd doesn't seem like it 
can offer much since it would be quite slow to do hashes or cryptographic 
functions.

-Jonathan




On Thursday, February 6, 2014 4:09 AM, i go bananas  wrote:
 
Has anything been done to try to marry these together yet?  
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Legal restrictions for apps

[Jonathan Wilkes]

On 02/05/2014 08:56 PM, Simon Wise wrote:

On 06/02/14 00:36, Dan Wilcox wrote:
Short answer: yes, it's sufficient to provide the object files and 
static

libs

As far as my understanding of GPL&  LGPL goes, you do not need to 
publish
your app sources when using LGPL libraries as the "Lesser" part of 
the LGPL

allows for distribution and is not viral.


yes, though 'viral' is a misleading term  ... the GPL does not, 
cannot, change any license for any other code, it is not infectious.


The GPL is certainly more restrictive (regarding re-distribution, not 
use, of the code covered) than for example the BSD or LGPL. It 
restricts the right to distribute/propagate as part of a larger work 
to works where the whole of the source code of that work is made 
available for reuse, modification and re-distribution either under the 
GPL or in any less restrictive way.


In the second case the GPLed code would no longer be licensed for 
distribution (and would have to be replaced or dropped or a different 
license negotiated with its copyright owners) if the work as a whole 
was modified and distributed with a more restrictive license. Whether 
this is useful or not has been very widely debated.


There are two debates.

One is between devs who license their code with the GPL and devs who 
license their code with 3-clause BSD.  Both share what they make with 
the world.  Both keep publicly auditable databases of the changes to the 
software.  Both encourage smart, safe ways to design and maintain 
software and operating systems.


BSD devs notice that when they share with GPL devs, the GPL devs say, 
"Thanks."  But when the BSD devs try to use what the GPL devs write they 
have to fuss with the license.  This is because the GPL essentially puts 
the golden rule into the license, whereas the BSD devs have a minimal 
license (probably as minimal as a license can be) and just follow the 
golden rule as human beings.


There are good reasons for both camps to do what they do, but it ends up 
requiring the BSD folks to care more about licenses than they'd like-- 
their license is only 3 clauses, after all!  So the BSD camp complains 
that when the GPL devs (like Linux Kernel devs) improve on code that was 
originally BSD, it comes back to the BSD folks "infected" with the GPL 
license which requires them to then care about licenses.  This is where 
the "viral" taunt comes from-- a genuine argument between two camps, 
both sharing what they make with everyone else to encourage a free and 
safe software ecosystem.


Another debate is between any company that produces proprietary software 
and a straw man in a corn field.  Here "viral" is irrelevant because the 
company isn't giving improvements back to the community.  Unfortunately 
this is probably what first pops to mind when people hear this 
argument-- that, somehow, the GPL can "infect" the business of selling a 
product and make it impossible for a company to make money.


But for better or for worse, we don't even need to consider minimal 
moral principles.  It's demonstrably dangerous to rely on software that 
doesn't have a pubic codebase and revision history. (Unfortunately I 
think it's for the better since most devs seem allergic to stating 
minimal moral principles.)


-Jonathan

The motivation for the GPL is stated in the license and the LGPL was 
written to cover some cases where the authors considered a less 
restrictive license useful.



Simon

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






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

Re: [PD] check mail with pd ?

[Jonathan Wilkes]

On 02/05/2014 05:29 PM, pured...@11h11.com wrote:

yes possible, for example using py/ext with a script like this one:
http://libgmail.sourceforge.net/

but pd is not really good with strings afaik


If you use Pd and have a use case where you're controling both the 
sending and receiving of the messages, then you can limit the message 
content to use only what Pd's message parser can handle.


Also, make sure the machine you're using has never had or will never 
have anything of interest on it.  On the other hand, I guess you could 
leave a Bitcoin wallet on there and think of your impending hack as a 
virtual Halloween treat.


-Jonathan


à+

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





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

Re: [PD] comments with trailing | ?

[Jonathan Wilkes]

On 01/24/2014 05:36 PM, Miller Puckette wrote:

Delete these lines in g_text.c:

 /* for comments, just draw a bar on RHS if unlocked; when a visible
 canvas is unlocked we have to call this anew on all comments, and when
 locked we erase them all via the annoying "commentbar" tag. */
 else if (x->te_type == T_TEXT && glist->gl_edit)
 {
 if (firsttime)
 sys_vgui(".x%lx.c create line\
  %d %d %d %d -tags [list %sR commentbar]\n",
 glist_getcanvas(glist),
 x2, y1,  x2, y2, tag);
 else
 sys_vgui(".x%lx.c coords %sR %d %d %d %d\n",
 glist_getcanvas(glist), tag, x2, y1,  x2, y2);
 }


(however, that won't disable the functionality; just the ugly marks.)

I'm still trying to think of something less ugly - tell me if you have any
ideas...


Just to give a concrete example, something like:

else if (x->te_type == T_TEXT && glist->gl_edit)
{
if (firsttime)
sys_vgui(".x%lx.c create rect %d %d %d %d "
"-dash {1 3} "
"-tags [list %sR commentbar]\n",
glist_getcanvas(glist), x1, y1, x2, y2, tag);
else
sys_vgui(".x%lx.c coords %sR %d %d %d %d\n",
glist_getcanvas(glist), tag, x1, y1, x2, y2);
}

Then you have a visual clue that the user is in editmode, with no 
ambiguity between the drawing and the text.


You can play with the dash values-- I chose those because it gives a 
clear contrast to broken boxes.  Use a larger 2nd integer to make the 
dashed box stand out less.


Btw-- I haven't tested this.  I'd be a lot more likely to try out code 
on Pd Vanilla 0.45 if someone could explain to me how to do incremental 
builds.  If I change a single line in g_text.c in 0.43 it only requires 
a single "make" that takes about 3 seconds.  Doing the same in 0.45 
requires "make clean && make", unnecessarily rebuilding all of Pd.  
Doing "make" in the src directory of 0.45 only rebuilds the things that 
need to recompile, but it doesn't update the binary, which makes it useless.


-Jonathan

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

Re: [PD] console font size really big

[Jonathan Wilkes]

On 01/30/2014 06:26 PM, Miller Puckette wrote:

Better than changing the font size globaly would be to change the
font sizes in tcl/pdwindow.tcl to negative numbers, which has the same
effect but only locally (instead of nuking everything.  The particular one
is:

 text .pdwindow.text -relief raised -bd 2 -font {-size 10} \
 -highlightthickness 0 -borderwidth 1 -relief flat \
 -yscrollcommand ".pdwindow.scroll set" -width 60 \
 -undo false -autoseparators false -maxundo 1 -takefocus 0

(change "size 10" to "size -10".)

Now I should think about whether to do that in the Pd source :)


That's a difficult choice.  On the one hand you'll get console output 
with similar sized font on each platform.  (Not pixel-exact btw because 
that depends on the font renderer.)  On the other you'll cause problems 
for the visually impaired who really do want point-sized fonts.


Of course the latter point only holds _if_ tcl/tk reports a sane number 
for [tk scaling].  That's probably not the case for OSX, and who knows 
for various GNU/Linux distros.  But I haven't looked to see whether this 
is remedied in tk 8.6.


Btw, for those exploring other GUI toolkits for Pd: choose QT.  It is as 
cross-platform as anything could be, has an enormous userbase, great 
documentation, and a _friendly_ community.  I cannot stress that last 
point enough.  If someone disagrees please try porting Pd's GUI to GTK; 
after you burn out from trying to deal with Gnome devs I'll buy you a beer.


-Jonathan



cheers
Miller

On Fri, Jan 24, 2014 at 06:25:23PM -0500, Jonathan Wilkes wrote:

On 01/24/2014 05:31 PM, Peter P. wrote:

Johnathan WIlkins wrote:


I'd be curious to know what window manager you are using.

Try going into pd-gui.tcl and find the line:
# tk scaling 1

Remove the "#", save the file, and then restart Pd.  See if that
solves the problem.
(Depending on how you are running Pd, you may need to have privileges
to edit that file)
-Jonathan

I am using fluxbox.

Indeed, editing /usr/local/lib/pd/tcl/pd-gui.tcl to yield
 tk scaling 1
solved the problem for me.

Interestingly there is a file /usr/local/bin/pd-gui.tcl present as
well, whose changes do not have an effet. This Pd is installed using
"make install" from within Miller's git sources. I wonder why
pd-gui.tcl is installed twice on my system, the latter one also being
in my $PATH.

Thank you again for this quick one Jonathan.

There is a comment related to tk scaling in this very file just above
the scaling option:
 # we are not using Tk scaling, so fix it to 1 on all platforms.  This
 # guarantees that patches will be pixel-exact on every platform
 # 2013.07.19 msp - trying without this to see what breaks - it's
 # having
 # deleterious effects on dialog window font sizes.

Would be interesting to know wonder what the deletrious effects were.

Tk has a very friendly but very small community without the
resources to make sure everything works as advertised across all
platforms.  So depending on which platform you use you'll see
different symptoms, depending on how well tk is integrated with the
guts of the window manager (in GNU/Linux, this would be "not at
all"), the accuracy of the info delivered to Tk from the OS/window
manager, implementation features/bugs in a particular graphics
subsystem, etc.

One detail is that if you let [tk scaling] do its thing, you'll see
problems in the postscript output if you print a patch.  There's an
ugly fix somewhere for this which requires hacking the ps output to
scale it by the tk scaling factor.

But if you hard code tk scaling to 1 users on Windows will see font
problems from Tk's half-baked, hardly documented theming engine that
would require _really_ ugly hacks all over Pd to fix.

-Jonathan


But, hey- problem solved for me.

thanks
cheers
P

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



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



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

Re: [PD] Software Defined Radio in Pd

[Jonathan Wilkes]

On 01/30/2014 06:41 AM, Julian Brooks wrote:

Hey all,

I've come across something I'd like to share with everyone.

Video demo
http://newblankets.org/video/Software%20Defined%20Radio%20in%20Pd.webm
(bit fuzzy but you'll get the drift)

The patches are here:
github: https://github.com/tkzic/pdsdr

This from the github page:

'What is this?

Here's a video of the basicSDR3.pd patch running with a soft66LC2 SDR: 
http://youtu.be/6sH6-DTU14E


Patches are running PdExtended 0.43-4 on MacOS. Although you will 
probably find you can get it run in Pd vanilla with tweaks.


The project is based on tutorial patches for the Max/MSP SDR project 
at: http://zerokidz.com/radio - They are documented at that site.


Externals: The source code is kind of a disaster. Please don't ask how 
to compile. We just figured out how to get this running in Pd a few 
days ago.'


Huge props to Tom Z for doing this.

I spoke to Tom briefly last week and he said that he has no time due 
to work commitments to deal with this again for another month or so, 
so I think it would be better if we left him alone for a bit.


There's a ton of stuff online to explain the concept further so for 
those interested I'd recommend some digging about.


The creative potential for applications of this concept are vast (I'm 
still getting my head around it to be honest).  He thought that it 
would be relatively trivial to turn the receiver into a transmitter 
which'd be pretty awesome.


Is there an extant decentralized system that can keep everyone's 
SDR-capable devices from interfering with everyone else's SDR-capable 
devices?


-Jonathan

 Even just making creative use of the endless variety of soundsources 
constantly transmitted unbeknownst to us is plenty for me to be 
getting on with.  But yeah, what an ear-opener.


Regards to all,

Julian


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


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

Re: [PD] Data structures and their clickable area

[Jonathan Wilkes]

On 01/29/2014 05:40 PM, Roman Haefeli wrote:

On Mon, 2014-01-27 at 21:34 -0500, Jonathan Wilkes wrote:

On 01/27/2014 05:35 PM, Roman Haefeli wrote:

Hi

I'm using a template consisting of a rectangle done with [filledpolygon]
and a number [drawnumber] in it. While mouse clicks anywhere in the area
of the rectangle are detected, it's only possible to change the number
with the keyboard when I exactly click on the number. Is there a way to
make the number catch the keyboard no matter where I click in the
rectangle?

One possibility is to make the hotspot bbox settable.

Actually, something like this would be on my wishlist. Knowing it does
not exist yet, I hoped for some kludge solution.


It would literally be five minutes of dev time.  But I'm not sure it's 
the ideal solution since often you want a hotspot to exceed the formal 
bounds of an object, and this wouldn't do that.


Still, I'll code it up and see how it works.




  Or maybe have a
method to forward widgetbehaviors to another drawing command.

Would certainly be interesting too, though having the hotspot area be
configurable would make this less important.


Probably best to just fool around with Raphael.js or some such library 
to see what it does, and see what can be ported.


-Jonathan



Anyway, thanks for your thoughts.

Roman


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





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

Re: [PD] Pd GUI freeze with error message(Tcl)

[Jonathan Wilkes]

On 01/29/2014 01:08 PM, Ivica Ico Bukvic wrote:

I've seen these also happen when something tries to address a non-existent
widget (e.g. when it is being closed or something similar).


There are a few things:
1) Weird treatment of the tk error window in OSX.  It looks like 
sometimes it causes an infinite loop, but I can't predictably generate 
the error.
2) If I understand it correctly, the tk event loop can run into the same 
problem the Pd audio dsp scheduler runs into with when you have too many 
calculations per dsp tick.  But it's worse with tk because it isn't 
optimized for doing timely graphics updates in the first place.  If you 
are sending a constant stream of just enough data to the gui that tk no 
longer has any idle time to update graphics, then you may get yourself 
into a situation where tk never updates and you see a freeze.


Moreover, tk seems not to use its idle time very efficiently.  I built a 
recursive loop for the search plugin specifically to let the user 
interact, cancel operations while building a search index.  But you can 
see how inefficient its drawing routine is.  (Maybe this has to do with 
X11 as well, but I think the sluggish redrawing happens on OSX too.)


This all is particularly problematic when combined with Pd's 
architecture, because it's often sending a barrage of messages to the 
gui.  For example:


* an error message to the console.  The console is fairly snappy when 
dealing with an email's worth of text, not so snappy when dealing with 
100 error messages being sent every 10ms.

* moving a large number of objects in Pd-extended or Vanilla
* moving an array in Pd-ext or Vanilla
* resizing an array where each element of the array is an svg tiger

-Jonathan


  There is an easy
way to prevent this from ever stopping GUI from working by encapsulating all
commands streaming from pd->gui with a simple catch{}. This is what
in part pd-l2ork does and I cannot remember when was the last time I had a
problem like this.


-Original Message-
From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of
Miller Puckette
Sent: Wednesday, January 29, 2014 12:29 AM
To: Jonghyun Kim
Cc: pd-list@iem.at
Subject: Re: [PD] Pd GUI freeze with error message(Tcl)

Hi Jong -

I think the "*(Tcl) INVALID COMMAND NAME' stuff isn't related to Pd

freezing,

but I'd like to find out how it happens and fix it.

The GUI can freeze if Pd is overloaded with audio computation on Mcintosh
compuers - the only thing I can suggest is reduce the amount of audio
computation (I know - nobody would ever want to do that :)

cheers
Miller

On Wed, Jan 29, 2014 at 04:03:17AM +0100, Jonghyun Kim wrote:

Hi list,

I don't know why this cause, but sometimes it appears and GUI freeze,

but

still Audio alive. Only GUI die...

Number Box, Vu meter, Sliders, and so on, these GUIs  all stop, and

don't

show the actual numbers...

Anyone knows this issue?

--
*(Tcl) INVALID COMMAND NAME: invalid command name ".x4de9a0.c"*
*while executing*
*"$tkcanvas itemconfig $tag -text $text"*
*(procedure "pdtk_text_set" line 2)*
*invoked from within*
*"pdtk_text_set .x4de9a0.c .x4de9a0.t395fcb0{98.13}"*
*("uplevel" body line 19)*
*invoked from within*
*"uplevel #0 $docmds"*
--

Pd-0.45-4 (32bit)
Mac OS X Mavericks

Screenshot attached.

Thanks,
Jong



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

http://lists.puredata.info/listinfo/pd-list


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


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





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

Re: [PD] Data structures and their clickable area

[Jonathan Wilkes]

On 01/27/2014 05:35 PM, Roman Haefeli wrote:

Hi

I'm using a template consisting of a rectangle done with [filledpolygon]
and a number [drawnumber] in it. While mouse clicks anywhere in the area
of the rectangle are detected, it's only possible to change the number
with the keyboard when I exactly click on the number. Is there a way to
make the number catch the keyboard no matter where I click in the
rectangle?


That's not possible.  Essentially what you want is to take a click from 
one draw command-- [filledpolygon]-- and "map" it or forward it to 
another-- [drawnumber].  Scalars don't give you any tools to hook in to 
a parent drawing command's widgetbehavior that way.



  Similarly, I'd like to be able to mouse-drag anywhere in the
rectangle in order to change the value of the number.


You could probably do it if you use a field variable to define hotspots 
on every 6x6 tile of the rectangle.  But you'd also have to constrain 
movement of the rectangle by abusing the quanta syntax, something like 
(-whatever:whatever)(0:0).  That would presumably constrain the field 
variable's screen coordinates so that it doesn't move when you 
click-drag it.  Then use the same field variable for your [drawnumber].


I'm almost finished with some new drawing instructions for data 
structures in Pd-l2ork that implement a subset of the svg spec. I've got 
some mouseover/mouseout widgetbehaviors working, but still nothing 
particularly sophisticated in terms of mapping mouse/keyboard 
interaction to field variables.


One possibility is to make the hotspot bbox settable.  Or maybe have a 
method to forward widgetbehaviors to another drawing command.


-Jonathan



Any ideas?

Roman



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



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