Re: [PD] "pd: exiting" on RPi running arch

[James Dunn]

For the archives, I've solved the issue - it seemed I just needed to 
install the package xf86-video-fbdev.


Quoth James Dunn, on 26/05/2013 18:06:

Quoth IOhannes zmölnig, on 26/05/2013 17:07:


so indeed, it's "-verbose" and "-verbose -verbose" (instead of "-v")



$ pd -verbose
Pd-0.43.4 ("") compiled 22:56:34 Aug  6 2012
port 5400
TCL_LIBRARY="/usr/lib/pd/lib/tcl/library" 
TK_LIBRARY="/usr/lib/pd/lib/tk/library"   wish 
"/usr/lib/pd/tcl//pd-gui.tcl" 5400

priority 6 scheduling enabled.
Waiting for connection request...
priority 8 scheduling enabled.
/usr/lib/pd/bin/pd-watchdog
... connected
pd: exiting
i missed that info in your original mail (please don't require anyone 
willing to answer to have read all your emails to this list and 
remember them :-))

sorry, thanks for your help so far!


check the various posts on this list about why [loadbang]->[; pd dsp 
1( often does not work. a simple workaround is to introduce a [delay 
1000] to start dsp only after some "boot time".
I'd forgotten about the [delay] for [loadbang] when turning the dsp on 
but it doesn't result in any sound when running in -nogui.


can you run
$ wish
via the ssh connection?


Yes, it opens a blank window on the local machine.


if so, Pd should be able to run fine.
which version of tcl/tk do you have installed?

tk-8.6.0-1
tcl-8.6.0-4


you could also try to run Pd without realtime priviliges
$ pd -nrt 

I tried that but it didn't help either.

___
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] Fwd: right angle connections

[Jonathan Wilkes]

 >From: Ivica Ico Bukvic 
>To: Jonathan Wilkes  
>Cc: Charles Goyard ; "pd-list@iem.at"  
>Sent: Friday, June 14, 2013 2:47 PM
>Subject: Re: [PD] Fwd: right angle connections
 


>On 06/14/2013 12:07 PM, Jonathan Wilkes wrote:


>
>>The real problem is: having the feature forces every pd flavor to
>>understand them at the file format level, even if not
  rendering it.
>
>If the "connect" method took A_GIMME you could just follow
  its
>initial four floats with a list of coordinates.
>
>-Jonathan
>
>Indeed. This is how pd-l2ork maintains backwards compatibility for a number of 
>features. That said, storing coordinates in the existing file format and/or 
>drawing the cord are not the problem. The problem is what happens when you 
>translate the object the cord is connected to? Uncovering logic whether all 
>the coordinates need to be translated (as opposed to only last one) is 
>something that even Max fails to do gracefully despite the fact it has been 
>capable of this for over 10 years, perhaps in part because there is no 
>perfect/graceful way to deal with this that does not require some fairly 
>evolved logic.

For problems like this we should probably look to the only arena that takes UX 
seriously: games.

There has to be some game designer who ran into exactly this problem and wrote 
a decent solution.

>Another challenge is cord selection. What needs to be checked is if
the existing cord selection logic is indeed robust to handle new
segmented cords. Although my memory is not what it used to be, as
far as I remember, the hitbox detection is fairly primitive when it
comes to cords and in its current form is not capable of gracefully
handling this. Please correct me if I am wrong.

You're probably right.  Having the editing logic on the c side means someone 
would have to code from scratch something
that probably takes a single statement in any gui toolkit--  even tk. :)

>Perhaps more pressing matter IMO is ability to multiselect cords so
that you can erase many of them at once without having to resort to
hack-ish ways of cutting and pasting objects.

Control-clicking on an empty part of a canvas currently does nothing.  
Control-click and dragging could leave a trail of 1px
rectangles (like the pencil tool in Gimp), and when the user releases the mouse 
button Pd could select all the wires that
have a point in common with the 1px trail.  (Then delete the 1px trail 
[.x5236f0 delete pixeltrail])

There's probably a more efficient way, though.

-Jonathan


-- 
Ivica Ico Bukvic, D.M.A
Composition, Music Technology
Director, DISIS Interactive Sound & Intermedia Studio
Director, L2Ork Linux Laptop Orchestra
Head, ICAT IMPACT Studio
Virginia Tech
Department of Music
Blacksburg, VA 24061-0240
(540) 231-6139
(540) 231-5034 (fax)
disis.music.vt.edu
l2ork.music.vt.edu
ico.bukvic.net___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Fwd: right angle connections

[Ivica Ico Bukvic]

On 06/14/2013 12:07 PM, Jonathan Wilkes wrote:


>The real problem is: having the feature forces every pd flavor to
>understand them at the file format level, even if not rendering it.

If the "connect" method took A_GIMME you could just follow its
initial four floats with a list of coordinates.

-Jonathan
Indeed. This is how pd-l2ork maintains backwards compatibility for a 
number of features. That said, storing coordinates in the existing file 
format and/or drawing the cord are not the problem. The problem is what 
happens when you translate the object the cord is connected to? 
Uncovering logic whether all the coordinates need to be translated (as 
opposed to only last one) is something that even Max fails to do 
gracefully despite the fact it has been capable of this for over 10 
years, perhaps in part because there is no perfect/graceful way to deal 
with this that does not require some fairly evolved logic.


Another challenge is cord selection. What needs to be checked is if the 
existing cord selection logic is indeed robust to handle new segmented 
cords. Although my memory is not what it used to be, as far as I 
remember, the hitbox detection is fairly primitive when it comes to 
cords and in its current form is not capable of gracefully handling 
this. Please correct me if I am wrong.


Perhaps more pressing matter IMO is ability to multiselect cords so that 
you can erase many of them at once without having to resort to hack-ish 
ways of cutting and pasting objects.


--
Ivica Ico Bukvic, D.M.A
Composition, Music Technology
Director, DISIS Interactive Sound & Intermedia Studio
Director, L2Ork Linux Laptop Orchestra
Head, ICAT IMPACT Studio
Virginia Tech
Department of Music
Blacksburg, VA 24061-0240
(540) 231-6139
(540) 231-5034 (fax)
disis.music.vt.edu
l2ork.music.vt.edu
ico.bukvic.net

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

Re: [PD] Fwd: right angle connections

[Jonathan Wilkes]

 >From: Charles Goyard 
>To: pd-list@iem.at 
>Sent: Friday, June 14, 2013 6:38 AM
>Subject: Re: [PD] Fwd: right angle connections
 

>Simon Wise wrote:
>> Its all really a matter of taste ... it has come up many many times
>> over the years, and nobody who could implement them seems to want
>> segmented cords enough to actually do the work.

>Desire Data did Bezier curves.

>Having the feature does not force people to use it.

>The real problem is: having the feature forces every pd flavor to
>understand them at the file format level, even if not rendering it.

If the "connect" method took A_GIMME you could just follow its
initial four floats with a list of coordinates.

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

Re: [PD] Fwd: right angle connections

[Jonathan Wilkes]

 >From: Simon Wise 
>To: pd-list@iem.at 
>Sent: Friday, June 14, 2013 4:37 AM
>Subject: Re: [PD] Fwd: right angle connections
 

>On 14/06/13 16:15, michael noble wrote:
>> On Fri, Jun 14, 2013 at 4:51 PM, Ivica Ico Bukvic  wrote:
>>
>>> While I agree with you that in most cases segmented patch cords are
>>> unnecessary, if you never have a need for them I presume you must be then
>>> using sends and receives for any situation where there is a feedback loop
>>> like:
>>>
>>> [object] x [object]
>>>
>>
>> Good point, I had a sneaking suspicion I was missing something. White space
>> helps here, but this is is the one case where I reluctantly tolerate some
>> obscuring the text.

>leaving the lines crossed this way also makes the construct instantly 
>recognisable.

>I find that with the addition of an occasional [t a] object and a few 
>send-return pairs when they give a clearer logical layout (plus putting 
>appropriate logically related sections of the code in subpatches) makes a 
>patch 
>very readable, while tracing out segmented cords in big patches in other 
>languages gets tiresome.

If segmented cords existed, morality would not suddenly go out the window.
You would still have subpatches and send/receive pairs to organize your patch.
Replacing your occassional [t a] object with a right angle cord isn't going to
make a patch harder to read.

>Its all really a matter of taste ... it has come up many many times over the 
>years, and nobody who could implement them seems to want segmented cords 
>enough 
>to actually do the work.

Segmented lines with straight and Bezier segments were implemented by majtu in
Desire Data.

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

[PD] [PD-announce] STEIM Summer Party 2013

[Marco Donnarumma]

JUNE 18

STEIM SUMMER PARTY 2013

It’s time again for STEIM’s annual summer party!

The packed program of artists this year include young bioacoustic performer
Marco Donnarumma, seminal Lebanese free improviser Mazen Kerbaj, and from
California we have Laetitia Sonami and James Fei presenting a new
collaboration for unstable instruments and modular synths. The evening will
also have special intimate performances by Daniel Schorno and Sybren Danz
in STEIM’s analog sound bunker. And to finish off the night some DJ sets by
DJ’s Foom and Snoid. Mark your calendar, it’s sure to be a blast!

Details
Date: Tuesday 18 June, 2013
Time: 20:30 (Door open 20:00)
Cost: €5
Location: STEIM Concert Space, Utrechtsedwasstraat 134, Amsterdam
**

*
*
--
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
___
Pd-announce mailing list
pd-annou...@iem.at
http://lists.puredata.info/listinfo/pd-announce
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Fwd: right angle connections

[Roman Haefeli]

On Fre, 2013-06-14 at 12:38 +0200, Charles Goyard wrote:
> Simon Wise wrote:
> > Its all really a matter of taste ... it has come up many many times
> > over the years, and nobody who could implement them seems to want
> > segmented cords enough to actually do the work.
> 
> Desire Data did Bezier curves.
> 
> Having the feature does not force people to use it.
> 
> The real problem is: having the feature forces every pd flavor to
> understand them at the file format level, even if not rendering it.

I'm not sure if this is really a problem. Pd 0.45 supports setting a box
width (for objects, messages, comments) that is saved with the patch.
Those patches still can be opened and read by previous versions of Pd.
This is done by storing the box width after a comma on the object
creation line:

#X obj 135 129 osc~ 3000, f 25;

Similarly, this could be done for connections:

#X connect 0 0 1 0, add some connection props here;

Of course, this information is lost when saving the patch with a Pd that
doesn't understand the format extension. Also, the extension might cause
an older Pd to print an error.

Roman






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

Re: [PD] how to install and use GPIO external

[Julian Brooks]

Meant to add:

Any other issues give us a shout and if I can help, I will.


On 13 June 2013 09:56, Julian Brooks  wrote:

> Hi Josh,
>
> The thread you're after is this one:
> gpio on the raspberry pi from within pd ?
>
> (ooh - big font)
>
> And Jaime's helpfile's attached.
>
>
> That should do it.
>
>
> Julian
>
>
>
> On 13 June 2013 06:37, Josh Downing  wrote:
>
>> I'm trying to figure out how to use the [gpio] external and I'm totally
>> lost on how to install it and then how to use it inside PD on my raspberry
>> pi. I did download the external from Miller Puckette's website but that is
>> about as far as I have been able to get. I would like to be able to
>> configure 4 GPIO pins as inputs and read their state within my PD patch.
>>
>> Could anyone provide me with any help on how I would go about installing
>> this patch and using it in PD on the pi? Also, I found a thread in the list
>> serve archive where someone had attached a draft of instructions on how to
>> install and use the GPIO external but unfortunately the attached file was
>> not available. Could someone send me these instructions if you have them?
>>
>> Thanks,
>> Josh
>>
>> ___
>> 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] Fwd: right angle connections

[Charles Goyard]

Simon Wise wrote:
> Its all really a matter of taste ... it has come up many many times
> over the years, and nobody who could implement them seems to want
> segmented cords enough to actually do the work.

Desire Data did Bezier curves.

Having the feature does not force people to use it.

The real problem is: having the feature forces every pd flavor to
understand them at the file format level, even if not rendering it.


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

Re: [PD] Fwd: right angle connections

[Simon Wise]

On 14/06/13 16:15, michael noble wrote:

On Fri, Jun 14, 2013 at 4:51 PM, Ivica Ico Bukvic  wrote:


While I agree with you that in most cases segmented patch cords are
unnecessary, if you never have a need for them I presume you must be then
using sends and receives for any situation where there is a feedback loop
like:

[object] x [object]



Good point, I had a sneaking suspicion I was missing something. White space
helps here, but this is is the one case where I reluctantly tolerate some
obscuring the text.


leaving the lines crossed this way also makes the construct instantly 
recognisable.

I find that with the addition of an occasional [t a] object and a few 
send-return pairs when they give a clearer logical layout (plus putting 
appropriate logically related sections of the code in subpatches) makes a patch 
very readable, while tracing out segmented cords in big patches in other 
languages gets tiresome.


Its all really a matter of taste ... it has come up many many times over the 
years, and nobody who could implement them seems to want segmented cords enough 
to actually do the work.




Simon

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

Re: [PD] Fwd: right angle connections

[michael noble]

On Fri, Jun 14, 2013 at 4:51 PM, Ivica Ico Bukvic  wrote:

> While I agree with you that in most cases segmented patch cords are
> unnecessary, if you never have a need for them I presume you must be then
> using sends and receives for any situation where there is a feedback loop
> like:
>
> [object] x [object]
>

Good point, I had a sneaking suspicion I was missing something. White space
helps here, but this is is the one case where I reluctantly tolerate some
obscuring the text.
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Fwd: right angle connections

[Ivica Ico Bukvic]

On 06/14/2013 01:03 AM, michael noble wrote:
On Fri, Jun 14, 2013 at 1:45 AM, Jonathan Wilkes > wrote:


They improve readability in situations where a straightforward,
structured
patch ends up with a line crossing over and obscuring text.


I'll go out on a limb as someone who rarely posts here. I've been 
working on a single complex patch, with many abstractions and 
sub-patches, for a long time now and one of the greatest pleasures of 
patching in PD for me is taking the time to avoid visual clutter 
within the constraints of working without right-angles or bezier curves.


There are basically three types of lines that look any good in PD to 
me - the horizontal cord, the vertical cord, and one particular 
diagonal in which the pixels just happen to align in a regular 
pattern. I would go so far as to say that working with only those 
three and sufficient white space one can avoid obscuring text in all 
situations. It takes longer because you have to think about where you 
place objects as well as what objects you are using, but I personally 
find I make better patching decisions based solely on the fact that I 
am forced to think longer about the patching process.


So long story short, I don't agree that right-angles or beziers are a 
requirement for clear, structured and readable patches. They may be 
helpful time-saving tools, but using them would come at a cost for me.


While I agree with you that in most cases segmented patch cords are 
unnecessary, if you never have a need for them I presume you must be 
then using sends and receives for any situation where there is a 
feedback loop like:


[object] x [object]

Segmented patch cords have their advantages, but like any tool, they can 
be also misused to produce even less readable patches. Time permitting 
and provided there is enough interest I may look into adding segmented 
patch cords into pd-l2ork.


Cheers!

--
Ivica Ico Bukvic, D.M.A
Composition, Music Technology
Director, DISIS Interactive Sound & Intermedia Studio
Director, L2Ork Linux Laptop Orchestra
Head, ICAT IMPACT Studio
Virginia Tech
Department of Music
Blacksburg, VA 24061-0240
(540) 231-6139
(540) 231-5034 (fax)
disis.music.vt.edu
l2ork.music.vt.edu
ico.bukvic.net

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