Re: [PD] How's Pd limited?

[Matt Barber]

Or if [fexpr~] is too expensive...

On Mon, Mar 14, 2016 at 12:00 AM, Chris McCormick 
wrote:

> On 25/02/16 22:39, i go bananas wrote:
>
>> real-time zero-crossing detection with sample-rate precision.
>>>
>>
>> if (incomingSignal > 0 && previousIncomingSignal < 0 || incomingSignal <
>> 0 || previousIncomingSignal > 0) return 1;
>> else return 0;
>>
>
> fexpr~ if (($x1[0] > 0 && $x1[-1] < 0) || ($x1[0] < 0 && $x1[-1] > 0), 1,
> 0);
>
> Cheers,
>
> Chris.
>
> --
> http://mccormick.cx/
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>


zero-crossing~-help.pd
Description: Binary data


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

Re: [PD] How's Pd limited?

[Chris McCormick]

On 25/02/16 22:39, i go bananas wrote:

real-time zero-crossing detection with sample-rate precision.


if (incomingSignal > 0 && previousIncomingSignal < 0 || incomingSignal <
0 || previousIncomingSignal > 0) return 1;
else return 0;


fexpr~ if (($x1[0] > 0 && $x1[-1] < 0) || ($x1[0] < 0 && $x1[-1] > 0), 
1, 0);


Cheers,

Chris.

--
http://mccormick.cx/

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

Re: [PD] How's Pd limited?

[Julian Brooks]

Thanks for clarification.
I made a mistake too
MOD = MOS dhurr

On 7 March 2016 at 14:12, Billy Stiltner  wrote:

>
>
> I see a mistake in my previous post.
> I used the term "Well Formed" in the wrong way.
>
> MOS = Well Formed
> EDO or equal division MOS have generator and period that are coprime.
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] How's Pd limited?

[Billy Stiltner]

I see a mistake in my previous post.
I used the term "Well Formed" in the wrong way.

MOS = Well Formed
EDO or equal division MOS have generator and period that are coprime.
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] How's Pd limited?

[Julian Brooks]

Hi Billy,

Have to admit much of that went over my limited skillset.
However, the MOD stuff is composition magic.

Thanks for sharing,

Julian

On 2 March 2016 at 13:55, Billy Stiltner  wrote:

> My struggles with it are not really limitations of pd.
> It's the way I have went about modelling a polyphonic synthesizer and
> using
> the tcl controls as MVC then making the controls a part of the preset
> machine.
> Everything is available  for me to break the view away from the DSP its
> just
> that there are some pretty nifty things going on with the view.
> For instance there are toggles that change the range of the envelope ADR
> controls
> so you can have 1s,3s, 10s, and 30s controls. This is dynamic controls.
> Another is a dial or knob that is quantized and the range changes
> depending on
> the number of intervals the scale has per equivalence interval or what I
> like to call the xTave
> , it is used to offset the frequency in a quantitative
> way in steps of the scale. It doesn't matter if the intervals are
> specified in cents ,JI,or an edo.
> The scales all end up in an frequency ratio list. So the knob is used to
> like the "tune" or "pitch"
> knob yet instead of continuous or cents adjustment it allows an offset
> based on the scale.
> There are 2 banks of oscillators and only one uses this kind of control,
> the other is just a regular dial
> that offsets by a floating point. At this point of development it was
> found that there were way too many
> controls and  being attached to the presets as well as the synthesizer's
> realtime adjustments.
> So Instead of making more controls I tried to reduce the amount of
> controls by changing the send
> and receive names dynamically. I guess it works for controls that are not
> dynamic but gets really
> complicated for the controls that have their properties change at runtime.
> Here is a thread about it.
> http://forum.pdpatchrepo.info/topic/5724/dollar-signs-in-objects-and-messages
> Also some discussion in this list.
> That can be solved once the controls are broke free from the presets and
> DSP.
> Making everything FUDI friendly with super neat message boxes and routing
> of messages through the first inlet like that can be seen in Miller's
> multi pickup guitar effects monster and
> patch repository or MAX/MSP XFM~  will be quite the task. Those are great
> examples of how patching should be.
> Branching away from puredata?
> Using javascript and the web browser dynamic html to make controls for the
> fractal sequencer.
> As well as a xenharmonic sequencer, a Moments of Symmetry(Erv Wilson)
> matrix generator
> to go along with Erv's mosedo.pdf There are 2 versions of it , one without
> the FUDI to pd stuff
> https://ia601408.us.archive.org/1/items/mosedo.html/mosedo.html?p=17=7
> , the other with and another expected soon
> that works with  any generator. The edo MOS are finite and are the "Well
> Formed" set of MOS,
> Finally Andrew Milne figured out how to calculate the cardinalities
> without using continued fractions  or brute force.
> So now it is quick to generate the non rational MOS alongside the closest
> approximating "Well Formed" MOS using very
> simple code which took forever to even comprehend on paper with pencil.
> Things like this are complex for me with pd
> Now that the algorithm is coded up in javascript a pd version would be
> simpler to make however , having this part of
> the puzzle in the browser will make it easier for a general audience to
> use.
> The new text object makes things like a database of modes easy to access
> in pd and also is easy enough
> to implement a user interface with the entire list on a webpage.  In pd a
> simple abstraction that increments
> an index for sets with {p} tones, an index for the modes of  sizes {s}
> , then the index into the modes {m} with
> s number of notes within  scales having p tones. Example:
> from
> http://www.huygens-fokker.org/docs/modename.html
> 14 tone equal modes: *2 3 2 2 3 2*Quasi-equal
> Hexatonic
> *2 1 2 1 2 1 2 2 1*  Gould Nonatonic
> *1 2 1 2 1 1 2 1 2 1*  Decimal-10
> *2 3 3 3 3*Godzilla-5
> *2 2 1 2 1 2 1 2 1*  Godzilla-9
> *3 2 2 3 2 2*Hedgehog-6
> *1 2 2 2 1 2 2 2*   Hedgehog-8
> *3 3 2 3 3* Semaphore-5
> *1 2 3 2 1 2 3*Superpelog-Pelog
> *1 2 1 2 1 2 1 2 2*Superpelog-9
>
> p=14,
> s=6,
> m=0*: 2 3 2 2 3 2*Quasi-equal Hexatonic
> m=1*: 3 2 2 3 2 2*Hedgehog-6
>
> For this set it is not too much to cycle through the entire list
> but for  12 and 31 edo there are many more modes.
> Would probably be ok to only divide the entire list up in files with
> the all the modes in scales with p tones instead of splitting up the list
> further.
>
> The list was easy to add user interactive  tags and mouseover
> functions
> that send the selected mode to the synthesizer in 

Re: [PD] How's Pd limited?

[Billy Stiltner]

My struggles with it are not really limitations of pd.
It's the way I have went about modelling a polyphonic synthesizer and using
the tcl controls as MVC then making the controls a part of the preset
machine.
Everything is available  for me to break the view away from the DSP its
just
that there are some pretty nifty things going on with the view.
For instance there are toggles that change the range of the envelope ADR
controls
so you can have 1s,3s, 10s, and 30s controls. This is dynamic controls.
Another is a dial or knob that is quantized and the range changes depending
on
the number of intervals the scale has per equivalence interval or what I
like to call the xTave
, it is used to offset the frequency in a quantitative
way in steps of the scale. It doesn't matter if the intervals are specified
in cents ,JI,or an edo.
The scales all end up in an frequency ratio list. So the knob is used to
like the "tune" or "pitch"
knob yet instead of continuous or cents adjustment it allows an offset
based on the scale.
There are 2 banks of oscillators and only one uses this kind of control,
the other is just a regular dial
that offsets by a floating point. At this point of development it was found
that there were way too many
controls and  being attached to the presets as well as the synthesizer's
realtime adjustments.
So Instead of making more controls I tried to reduce the amount of controls
by changing the send
and receive names dynamically. I guess it works for controls that are not
dynamic but gets really
complicated for the controls that have their properties change at runtime.
Here is a thread about it.
http://forum.pdpatchrepo.info/topic/5724/dollar-signs-in-objects-and-messages
Also some discussion in this list.
That can be solved once the controls are broke free from the presets and
DSP.
Making everything FUDI friendly with super neat message boxes and routing
of messages through the first inlet like that can be seen in Miller's multi
pickup guitar effects monster and
patch repository or MAX/MSP XFM~  will be quite the task. Those are great
examples of how patching should be.
Branching away from puredata?
Using javascript and the web browser dynamic html to make controls for the
fractal sequencer.
As well as a xenharmonic sequencer, a Moments of Symmetry(Erv Wilson)
matrix generator
to go along with Erv's mosedo.pdf There are 2 versions of it , one without
the FUDI to pd stuff
https://ia601408.us.archive.org/1/items/mosedo.html/mosedo.html?p=17=7 ,
the other with and another expected soon
that works with  any generator. The edo MOS are finite and are the "Well
Formed" set of MOS,
Finally Andrew Milne figured out how to calculate the cardinalities without
using continued fractions  or brute force.
So now it is quick to generate the non rational MOS alongside the closest
approximating "Well Formed" MOS using very
simple code which took forever to even comprehend on paper with pencil.
Things like this are complex for me with pd
Now that the algorithm is coded up in javascript a pd version would be
simpler to make however , having this part of
the puzzle in the browser will make it easier for a general audience to
use.
The new text object makes things like a database of modes easy to access in
pd and also is easy enough
to implement a user interface with the entire list on a webpage.  In pd a
simple abstraction that increments
an index for sets with {p} tones, an index for the modes of  sizes {s}
, then the index into the modes {m} with
s number of notes within  scales having p tones. Example:
from
http://www.huygens-fokker.org/docs/modename.html
14 tone equal modes: *2 3 2 2 3 2*Quasi-equal Hexatonic
*2 1 2 1 2 1 2 2 1*  Gould Nonatonic
*1 2 1 2 1 1 2 1 2 1*  Decimal-10
*2 3 3 3 3*Godzilla-5
*2 2 1 2 1 2 1 2 1*  Godzilla-9
*3 2 2 3 2 2*Hedgehog-6
*1 2 2 2 1 2 2 2*   Hedgehog-8
*3 3 2 3 3* Semaphore-5
*1 2 3 2 1 2 3*Superpelog-Pelog
*1 2 1 2 1 2 1 2 2*Superpelog-9

p=14,
s=6,
m=0*: 2 3 2 2 3 2*Quasi-equal Hexatonic
m=1*: 3 2 2 3 2 2*Hedgehog-6

For this set it is not too much to cycle through the entire list
but for  12 and 31 edo there are many more modes.
Would probably be ok to only divide the entire list up in files with
the all the modes in scales with p tones instead of splitting up the list
further.

The list was easy to add user interactive  tags and mouseover functions
that send the selected mode to the synthesizer in javascript and html.

With the text object the user interface is a little different.
It's only a float atom index  into the list,  a canvas display for the
currently selected
item in the list. , and a bang to send the mode off to where it can be
used  vs the entire
interactive scrollable list in the browser.  Some of the modes are specific
to other scales
that are Just Intonation as well as cents  rather than equal 

Re: [PD] How's Pd limited?

[Lucas Cordiviola]

For me Pd is totally
outstanding, even more with the Cleveland/Cincinnati
spaghetti reports.



The Gui is ok, perhaps
more than ok, as it is. When you are patching you always change
things, and the final visual effect is irrelevant. Also straight
cables (or unsegmented) are clear to follow. This minimalism, I
guess, is simpler an cheaper to maintain, that makes it even better.



Help files are ok.



It`s well documented.



Works on windows, mac,
linux, etc.



Limitations are that
Pd-extended is no longer updated, also that Pdvst by J.Sarlo is no
longer updated. Both of these form a door in which beginners enters
“Computer Music” and “dsp” with Pd.








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

Re: [PD] How's Pd limited?

[Antoine Rousseau]

I also feel more limited than Pd.

2016-02-25 22:14 GMT+01:00 Matt Barber :

>
>
> On Thu, Feb 25, 2016 at 3:29 PM, Billy Stiltner 
> wrote:
>
>>
>> this is a trick question
>> pd is not limited, it is the most object oriented c code you will ever
>> see in the entire universe.
>> with some practice you can learn how to model high level polymorphic
>> virtual destructors.
>>
>>
>>
> ​This must explain the recurring nightmares I have when I'm deep in
> constructing a large patch: I'll​ dream that I have to use Pd to stop a
> missile that's headed for Cleveland. It's always Cleveland.
>
>
>
>
>
>
>>
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>


-- 
Antoine Rousseau
  http://www.metalu.net  __
http://www.metaluachahuter.com/

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

Re: [PD] How's Pd limited?

[Matt Barber]

Spaghetti is more of a Cincinnati thing.

http://www.skylinechili.com/ways.php

On Thu, Feb 25, 2016 at 4:42 PM, Jonathan Wilkes  wrote:

> > It's always Cleveland.
>
> You'd probably work like the dickens and make a patch that saves
> Cleveland.  But the next day when they attack
> another city you'd open up the patch and be unable to make sense of all
> your spaghetti.
>
> At least you could use your Cleveland-saving patch as a prototype to sell
> software to the DoD.
>
> -Jonathan
>
>
> On Thursday, February 25, 2016 4:14 PM, Matt Barber 
> wrote:
>
>
>
>
> On Thu, Feb 25, 2016 at 3:29 PM, Billy Stiltner 
> wrote:
>
>
> this is a trick question
> pd is not limited, it is the most object oriented c code you will ever see
> in the entire universe.
> with some practice you can learn how to model high level polymorphic
> virtual destructors.
>
>
>
> ​This must explain the recurring nightmares I have when I'm deep in
> constructing a large patch: I'll​ dream that I have to use Pd to stop a
> missile that's headed for Cleveland. It's always Cleveland.
>
>
>
>
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] How's Pd limited?

[Alexandre Torres Porres]

I see what's happening

the fb receive is sending the same number over and over for the whole 64
block

when subtracting from the count input, we get a block that goes from 1 to
64.

snapshot is giving me the first value (1), your magic glass is giving you
the last (64).

And I just acted too soon when I saw this today and thought I had found gold

I haven't thought about it yet, but I wonder if something like I described
could be done somehow, or if it is "physically impossible".

well, now I'm off the dentist and going to the yoga class, too much things
on my day are ruining my pd quality time...

cheers

2016-02-25 17:21 GMT-03:00 martin brinkmann :

> On 25/02/16 20:45, Alexandre Torres Porres wrote:
> > well, I was able to replicate my test with count...
> >
> > not sure what's happening, but that's it, a one sample delay in feedback,
> > for what it seems
>
> it looks as if cyclone/snapshot~ does not work like it should.
> when i turn on "magic glass" it shows "64", while the
> snapshot outputs "1".
>
> > I gotta go into my dentist now, whish me luck
>
> good luck!
> maybe the sounds of the test-patches have been a good preparation
> for (at least the acoustic) things to come. ;-)
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] How's Pd limited?

[Jonathan Wilkes via Pd-list]

> It's always Cleveland.
You'd probably work like the dickens and make a patch that saves Cleveland.  
But the next day when they attack 
another city you'd open up the patch and be unable to make sense of all your 
spaghetti.
At least you could use your Cleveland-saving patch as a prototype to sell 
software to the DoD.

-Jonathan
 

On Thursday, February 25, 2016 4:14 PM, Matt Barber  
wrote:
 

 

On Thu, Feb 25, 2016 at 3:29 PM, Billy Stiltner  
wrote:


this is a trick question
pd is not limited, it is the most object oriented c code you will ever see in 
the entire universe.
with some practice you can learn how to model high level polymorphic virtual 
destructors.




​This must explain the recurring nightmares I have when I'm deep in 
constructing a large patch: I'll​ dream that I have to use Pd to stop a missile 
that's headed for Cleveland. It's always Cleveland.



 

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




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


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

Re: [PD] How's Pd limited?

[Matt Barber]

On Thu, Feb 25, 2016 at 3:29 PM, Billy Stiltner 
wrote:

>
> this is a trick question
> pd is not limited, it is the most object oriented c code you will ever see
> in the entire universe.
> with some practice you can learn how to model high level polymorphic
> virtual destructors.
>
>
>
​This must explain the recurring nightmares I have when I'm deep in
constructing a large patch: I'll​ dream that I have to use Pd to stop a
missile that's headed for Cleveland. It's always Cleveland.






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

Re: [PD] How's Pd limited?

[Billy Stiltner]

this is a trick question
pd is not limited, it is the most object oriented c code you will ever see
in the entire universe.
with some practice you can learn how to model high level polymorphic
virtual destructors.
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] How's Pd limited?

[martin brinkmann]

On 25/02/16 20:45, Alexandre Torres Porres wrote:
> well, I was able to replicate my test with count...
> 
> not sure what's happening, but that's it, a one sample delay in feedback,
> for what it seems

it looks as if cyclone/snapshot~ does not work like it should.
when i turn on "magic glass" it shows "64", while the
snapshot outputs "1".

> I gotta go into my dentist now, whish me luck

good luck!
maybe the sounds of the test-patches have been a good preparation
for (at least the acoustic) things to come. ;-)



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

Re: [PD] How's Pd limited?

[Alexandre Torres Porres]

well, I was able to replicate my test with count...

not sure what's happening, but that's it, a one sample delay in feedback,
for what it seems

I gotta go into my dentist now, whish me luck



2016-02-25 16:38 GMT-03:00 Alexandre Torres Porres :

> > would be great if it worked. (i've tried similar tricks...)
>
> yeah, don't know what happened, when I tried with count~ it seemed to
> work, for my own surprise, I wasn;t expecting it to work either. Now I have
> no idea what happened.
>
> I may have also just gone insane for good :)
>
> 2016-02-25 14:52 GMT-03:00 martin brinkmann :
>
>> On 25/02/16 18:09, Alexandre Torres Porres wrote:
>> > 2016-02-25 13:57 GMT-03:00 martin brinkmann :
>> >
>> >> if you want feedback in a complex patch,
>> >> (like these virtual-virtual-modular-systems) the only thing
>> >> you can do is to reblock everything to 1, which is not always possible
>> >> (due to high cpu load, conflicting blocksizes, whatever).
>> >>
>> >
>> > This was addressed only to me, let me reply to the list.
>>
>> sorry, i pressed the wrong reply button.
>>
>> > I never needed to do it in a super complex patch, but anyway, what
>> you're
>> > saying is not true. Here's how you can do it.
>> >
>> > Have your crazy complex patch running around all over the place.
>> >
>> > Now, for your feedback loop, you need to create a subpatch to "send it".
>> >
>> > Make it [pd fb_send]
>> >
>> > in it, create a short delay line, give it a cool name like $0-fb, use
>> > [block~ 1].
>> >
>> > then, for your feedback receive, have another subpatch [pd fb_receive].
>> In
>> > it, use [delread~ $0-fb 0].
>>
>> would be great if it worked. (i've tried similar tricks...)
>>
>> >
>> > voilá...
>> >
>> > check my self frequency modulating oscillator patch attached
>>
>> the delayed signal is not a sine, when the blocksize in the
>> receive is <64.
>>
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>
>


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

Re: [PD] How's Pd limited?

[Alexandre Torres Porres]

> would be great if it worked. (i've tried similar tricks...)

yeah, don't know what happened, when I tried with count~ it seemed to work,
for my own surprise, I wasn;t expecting it to work either. Now I have no
idea what happened.

I may have also just gone insane for good :)

2016-02-25 14:52 GMT-03:00 martin brinkmann :

> On 25/02/16 18:09, Alexandre Torres Porres wrote:
> > 2016-02-25 13:57 GMT-03:00 martin brinkmann :
> >
> >> if you want feedback in a complex patch,
> >> (like these virtual-virtual-modular-systems) the only thing
> >> you can do is to reblock everything to 1, which is not always possible
> >> (due to high cpu load, conflicting blocksizes, whatever).
> >>
> >
> > This was addressed only to me, let me reply to the list.
>
> sorry, i pressed the wrong reply button.
>
> > I never needed to do it in a super complex patch, but anyway, what you're
> > saying is not true. Here's how you can do it.
> >
> > Have your crazy complex patch running around all over the place.
> >
> > Now, for your feedback loop, you need to create a subpatch to "send it".
> >
> > Make it [pd fb_send]
> >
> > in it, create a short delay line, give it a cool name like $0-fb, use
> > [block~ 1].
> >
> > then, for your feedback receive, have another subpatch [pd fb_receive].
> In
> > it, use [delread~ $0-fb 0].
>
> would be great if it worked. (i've tried similar tricks...)
>
> >
> > voilá...
> >
> > check my self frequency modulating oscillator patch attached
>
> the delayed signal is not a sine, when the blocksize in the
> receive is <64.
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] How's Pd limited?

[David Medine]

BTW, this is germane to some work that I have been doing and it just so 
happens that I have a figure handy.


In the figure are the spectra for two oscillators frequency modulating 
each other in a tight feedback loop. The first two were made with FM 
oscillators adapted from Pd's FM example patch. The first spectrum was 
recorded using block 64 and the second at block 1. The third was made 
using a dynamical model (which is, incidentally, the principle behind 
the [bob~] object) of two oscillators in an FM regime. This better 
approximates 0 time delay. It should be clear how much distortion even 1 
sample of delay in the loop causes in this particular situation.


Unfortunately, the answer for how to do this in Pd is 'write an extern' 
-- hence [bob~]. So far there is no such thing as an unsampled, 
real-time patching environment.


On 02/25/2016 09:52 AM, martin brinkmann wrote:

On 25/02/16 18:09, Alexandre Torres Porres wrote:

2016-02-25 13:57 GMT-03:00 martin brinkmann :


if you want feedback in a complex patch,
(like these virtual-virtual-modular-systems) the only thing
you can do is to reblock everything to 1, which is not always possible
(due to high cpu load, conflicting blocksizes, whatever).


This was addressed only to me, let me reply to the list.

sorry, i pressed the wrong reply button.


I never needed to do it in a super complex patch, but anyway, what you're
saying is not true. Here's how you can do it.

Have your crazy complex patch running around all over the place.

Now, for your feedback loop, you need to create a subpatch to "send it".

Make it [pd fb_send]

in it, create a short delay line, give it a cool name like $0-fb, use
[block~ 1].

then, for your feedback receive, have another subpatch [pd fb_receive]. In
it, use [delread~ $0-fb 0].

would be great if it worked. (i've tried similar tricks...)


voilá...

check my self frequency modulating oscillator patch attached

the delayed signal is not a sine, when the blocksize in the
receive is <64.

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


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

Re: [PD] How's Pd limited?

[martin brinkmann]

On 25/02/16 18:09, Alexandre Torres Porres wrote:
> 2016-02-25 13:57 GMT-03:00 martin brinkmann :
> 
>> if you want feedback in a complex patch,
>> (like these virtual-virtual-modular-systems) the only thing
>> you can do is to reblock everything to 1, which is not always possible
>> (due to high cpu load, conflicting blocksizes, whatever).
>>
> 
> This was addressed only to me, let me reply to the list.

sorry, i pressed the wrong reply button.

> I never needed to do it in a super complex patch, but anyway, what you're
> saying is not true. Here's how you can do it.
> 
> Have your crazy complex patch running around all over the place.
> 
> Now, for your feedback loop, you need to create a subpatch to "send it".
> 
> Make it [pd fb_send]
> 
> in it, create a short delay line, give it a cool name like $0-fb, use
> [block~ 1].
> 
> then, for your feedback receive, have another subpatch [pd fb_receive]. In
> it, use [delread~ $0-fb 0].

would be great if it worked. (i've tried similar tricks...)

> 
> voilá...
> 
> check my self frequency modulating oscillator patch attached

the delayed signal is not a sine, when the blocksize in the
receive is <64.

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

Re: [PD] How's Pd limited?

[Alexandre Torres Porres]

I had tested with count~ before and the result was clearly a one sample
delay, subtracting the output of count to a feedback line gave me the
result of 1.

I'll test it again later

2016-02-25 14:38 GMT-03:00 cyrille henry :

>
>
> Le 25/02/2016 18:09, Alexandre Torres Porres a écrit :
>
>>
>> 2016-02-25 13:57 GMT-03:00 martin brinkmann > >:
>>
>> if you want feedback in a complex patch,
>> (like these virtual-virtual-modular-systems) the only thing
>> you can do is to reblock everything to 1, which is not always possible
>> (due to high cpu load, conflicting blocksizes, whatever).
>>
>>
>> This was addressed only to me, let me reply to the list.
>>
>> I never needed to do it in a super complex patch, but anyway, what you're
>> saying is not true. Here's how you can do it.
>>
>> Have your crazy complex patch running around all over the place.
>>
>> Now, for your feedback loop, you need to create a subpatch to "send it".
>>
>> Make it [pd fb_send]
>>
>> in it, create a short delay line, give it a cool name like $0-fb, use
>> [block~ 1].
>>
>> then, for your feedback receive, have another subpatch [pd fb_receive].
>> In it, use [delread~ $0-fb 0].
>>
>> voilá...
>>
>> check my self frequency modulating oscillator patch attached
>>
> your patch did not work with 1 sample delay.
> to test : remove the block~ 1 object, and the sound did not change.
>
> put everything in a subpatch, add a block~ 1 object, and the sound change
> (and get better)
>
> There are 2 problem in you patch :
> nothing force the writer to be computed before the reader. you can add a
> dummy audio connection between writer and reader to force execution order
> of the 2 subpatch.
> see miller exemple G05.
>
> But the main problem is that the osc run with 64 block size. there is no
> way to have less than 64 sample delay between osc frequency in and osc
> output.
>
>
> In order to have feedback in a very complex patch, you need to block~
> everything to 1.
>  cheers
> c
>
>
>> cheers
>>
>>
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] How's Pd limited?

[cyrille henry]

Le 25/02/2016 18:09, Alexandre Torres Porres a écrit :


2016-02-25 13:57 GMT-03:00 martin brinkmann >:

if you want feedback in a complex patch,
(like these virtual-virtual-modular-systems) the only thing
you can do is to reblock everything to 1, which is not always possible
(due to high cpu load, conflicting blocksizes, whatever).


This was addressed only to me, let me reply to the list.

I never needed to do it in a super complex patch, but anyway, what you're 
saying is not true. Here's how you can do it.

Have your crazy complex patch running around all over the place.

Now, for your feedback loop, you need to create a subpatch to "send it".

Make it [pd fb_send]

in it, create a short delay line, give it a cool name like $0-fb, use [block~ 
1].

then, for your feedback receive, have another subpatch [pd fb_receive]. In it, 
use [delread~ $0-fb 0].

voilá...

check my self frequency modulating oscillator patch attached

your patch did not work with 1 sample delay.
to test : remove the block~ 1 object, and the sound did not change.

put everything in a subpatch, add a block~ 1 object, and the sound change (and 
get better)

There are 2 problem in you patch :
nothing force the writer to be computed before the reader. you can add a dummy 
audio connection between writer and reader to force execution order of the 2 
subpatch.
see miller exemple G05.

But the main problem is that the osc run with 64 block size. there is no way to 
have less than 64 sample delay between osc frequency in and osc output.


In order to have feedback in a very complex patch, you need to block~ 
everything to 1.
 
cheers

c



cheers


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



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

Re: [PD] How's Pd limited?

[Claude Heiland-Allen]

On 25/02/16 02:22, Alexandre Torres Porres wrote:

easy have hard synced oscillators


phasor~ 100
 |
*~ 2.666
 |
wrap~
 |
dac~


doing it bandlimited so it doesn't sound like poop is a lot harder
(you can get part of the way there by oversampling with filtering)


Claude
--
http://mathr.co.uk

#N canvas 1 51 335 291 10;
#X obj 72 102 mtof;
#X obj 72 124 vline~;
#X obj 72 146 lop~ 15;
#X obj 72 168 phasor~;
#X obj 72 190 *~;
#X obj 72 212 wrap~;
#X obj 72 234 hip~ 1;
#X obj 62 264 dac~;
#X obj 70 37 metro 444;
#X obj 70 59 random 25;
#X obj 70 81 + 29;
#X msg 166 131 8 \, 1 444;
#X obj 166 153 vline~;
#X obj 71 17 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1
;
#X msg 199 215 \; pd dsp 1;
#X connect 0 0 1 0;
#X connect 1 0 2 0;
#X connect 2 0 3 0;
#X connect 3 0 4 0;
#X connect 4 0 5 0;
#X connect 5 0 6 0;
#X connect 6 0 7 0;
#X connect 6 0 7 1;
#X connect 8 0 9 0;
#X connect 8 0 11 0;
#X connect 9 0 10 0;
#X connect 10 0 0 0;
#X connect 11 0 12 0;
#X connect 12 0 4 1;
#X connect 13 0 8 0;
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] How's Pd limited?

[Alexandre Torres Porres]

2016-02-25 13:57 GMT-03:00 martin brinkmann :

> if you want feedback in a complex patch,
> (like these virtual-virtual-modular-systems) the only thing
> you can do is to reblock everything to 1, which is not always possible
> (due to high cpu load, conflicting blocksizes, whatever).
>

This was addressed only to me, let me reply to the list.

I never needed to do it in a super complex patch, but anyway, what you're
saying is not true. Here's how you can do it.

Have your crazy complex patch running around all over the place.

Now, for your feedback loop, you need to create a subpatch to "send it".

Make it [pd fb_send]

in it, create a short delay line, give it a cool name like $0-fb, use
[block~ 1].

then, for your feedback receive, have another subpatch [pd fb_receive]. In
it, use [delread~ $0-fb 0].

voilá...

check my self frequency modulating oscillator patch attached

cheers


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

Re: [PD] How's Pd limited?

[Alexandre Torres Porres]

2016-02-25 12:47 GMT-03:00 Christof Ressi :

> > you could easy have hard synced oscillators, but no...
>
> yes, you can, with a little trick. See my abstraction (needs zexy).
>

I have a simple vanilla trick already :)
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] How's Pd limited?

[Matt Barber]

You don't even need that much logic for zero crossings. They are easy to
find using some simple arithmetic. See attached.

On Thu, Feb 25, 2016 at 9:39 AM, i go bananas  wrote:

> >real-time zero-crossing detection with sample-rate precision.
>
> this is something that is super simple to implement.
>
> it's like:
>
> if (incomingSignal > 0 && previousIncomingSignal < 0 || incomingSignal <
> 0 || previousIncomingSignal > 0) return 1;
> else return 0;
>
> i also don't understand why such an easy tool has never been put into
> vanilla pd.
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>


zero-crossing~-help.pd
Description: Binary data


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

Re: [PD] How's Pd limited?

[Alexandros Drymonitis]

On Thu, Feb 25, 2016 at 4:19 PM, Alexandre Torres Porres 
wrote:

>
> 2016-02-25 6:49 GMT-03:00 peiman khosravi :
>
>> Two example I can think of. One-sample delay/feedback for filter design
>> etc. And real-time zero-crossing detection with sample-rate precision.
>
>
> you can do that in Pd vanilla with a single object: [fexpr~]
>
Don't know if anybody already mentioned it, but someone on Pd's forum
posted this
http://forum.pdpatchrepo.info/topic/9859/jsusfx-jesusonic-external-for-pure-data
which is an external that can use the JSFX scripting language and works per
sample (as the author says in the forum post). He says that it's quite CPU
intensive but he's working on it..
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] How's Pd limited?

[i go bananas]

>real-time zero-crossing detection with sample-rate precision.

this is something that is super simple to implement.

it's like:

if (incomingSignal > 0 && previousIncomingSignal < 0 || incomingSignal < 0
|| previousIncomingSignal > 0) return 1;
else return 0;

i also don't understand why such an easy tool has never been put into
vanilla pd.
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] How's Pd limited?

[Alexandre Torres Porres]

2016-02-25 6:49 GMT-03:00 peiman khosravi :

> Two example I can think of. One-sample delay/feedback for filter design
> etc. And real-time zero-crossing detection with sample-rate precision.


you can do that in Pd vanilla with a single object: [fexpr~]

like I said, I guess there's nothing you can do in gen~ that you can't in
Pd, either as a patch or in [fexpr~]. Perhaps the selling point of gen~ is
being more efficient. But hey, I was just wondering how heavier Max/MSP is
altogether with the whole interface and all. I mean, you can run Pd easily
on a raspberry pi 0...

But in terms of efficiency, I guess nothing beats SuperCollider.

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

Re: [PD] How's Pd limited?

[Joe White]

Hey Chris,

Here's a vanilla tanh~ version that doesn't involve a table lookup

https://github.com/enzienaudio/heavylib/blob/master/hv_tanh.pd

Cheers,
Joe

On 25 February 2016 at 04:03, Chris McCormick  wrote:

> Hello,
>
> On 24/02/16 17:23, Alexandros Drymonitis wrote:
>
>> If you copy the [tanh] abstraction from purepd and make it a signal one,
>> doesn't that work? Then it's vanilla.
>>
>
> expr~ is available in all versions of Pd and has the same license.
>
> It is probably slower than making a table, so doing what you said is a
> good idea for optimisation. Here is an abstraction that does what you
> describe:
>
> https://github.com/chr15m/blockhead/blob/master/e_tanh.pd
>
>
> Cheers,
>
> Chris.
>
> --
> http://mccormick.cx/
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] How's Pd limited?

[peiman khosravi]

Two example I can think of. One-sample delay/feedback for filter design
etc. And real-time zero-crossing detection with sample-rate precision.

On Wednesday, February 24, 2016, Matt Barber  wrote:

> How fine-grained does it need to be? As long as all the parameters are
> known at the beginning of the block, you have everything you need. As far
> as human interaction is concerned, 64-sample blocks are extremely
> fine-grained. The individual cycles of the pitches at the beginning of
> Beethoven's 5th are coarser grained. For computer generated events, there
> are ways to schedule events to begin in the middle of a block.
>
> The idea of a kind of Pd JIT compiler is interesting, though.
>
> On Wed, Feb 24, 2016 at 4:54 PM, Brian Fay  > wrote:
>
>> The issue with blocking is that you don't have fine-grained control of an
>> audio, process, right? If you want that level of fine-grained control, you
>> either need to explicitly set the blocksize to 1 in your patch/sub-patch,
>> or you need to actually dig into the C code for the externals and change
>> the logic there (which requires you write C code, recompile things, restart
>> Pd...).
>>
>> Theoretically, there could be a way to swap out the code for an external
>> while Pd is running, rather than restarting Pd. Still, you'd have to write
>> C and pray that you didn't introduce some terrible bug.
>>
>> But theoretically, instead of writing externals in C, couldn't we come up
>> with a high-level representation of a Pd external in a visual programming
>> environment similar to Pd? Then we could compile that down to an external,
>> and actually use it in our Pd patch, without actually reloading Pd. It
>> sounds very difficult, but I imagine gen~ does something like that.
>>
>> For reference, I believe Extempore provides the ability to edit and
>> replace a low-level audio process while the program is running (I'll have
>> to rewatch some conference videos to confirm that).
>>
>> On Wed, Feb 24, 2016 at 3:41 PM, Matt Barber > > wrote:
>>
>>> OK, now I'm having trouble even imagining how an unblocked audio model
>>> could possibly behave (at least, as David points out, in a real-time
>>> context).
>>>
>>> On Wed, Feb 24, 2016 at 2:58 PM, David Medine >> > wrote:
>>>
 This doesn't answer Matt's question at all (apologies), but just as a
 clarification, ChucK *does *block audio. It's just that ChucK always
 blocks at the minimum size of 1 sample per block. 1 is still a block size
 though, and it still implies the same problems associated with order of
 operations, feedback, interpolating control input, and parallelization that
 a block size of 64 does.

 Also, maybe this has already been pointed out on this thread, but block
 1 is super slow because it means that you have to load all your DSP
 functions onto the CPU cache every 1/SR seconds instead of 64/SR seconds.
 Blocking by 64 buys a lot. Having a locally adjustable block size is a
 great feature (that ChucK lacks) because you can do it for special needs
 cases (like variable delay patches, for example).

 Anyway, in my opinion, the block thing isn't a limit to Pd, but a limit
 to real-time digital signal processing.



 On 2/24/2016 11:27 AM, Matt Barber wrote:

 Are there any other DSP environments besides ChucK that don't block
 audio? Last time I tried ChucK (2012?) its efficiency was still abysmal.
 [block~ 1] definitely takes a hit, but it's usually possible to minimize
 how much of the DSP chain is actually blocked at 1. I guess with Csound you
 can specify a k-rate equal to the sample rate which is also effectively a
 single sample block. I haven't ever used Csound in a real-time context, and
 most of what I do with it compiles much more slowly than real time in any
 case.

 On Wed, Feb 24, 2016 at 1:44 PM, peiman khosravi <
 peimankhosr...@gmail.com
 > wrote:

> You can do this with MSP's poly~ too but I'm guessing that the CPU
> costs are quite heavy. Moreover, there are operators in gen that are
> designed for low-level operations.
>
>
> *www.peimankhosravi.co.uk  *
>
> On 24 February 2016 at 16:15, cyrille henry <
> c...@chnry.net
> > wrote:
>
>>
>>
>> Le 24/02/2016 16:50, peiman khosravi a écrit :
>>
>>> One great advantage of maxmsp is gen, which gives you sample-level
>>> patching with the possibility of a one-sample delay.
>>>
>>>
>> you can use 

Re: [PD] How's Pd limited?

[Chris McCormick]

Hello,

On 24/02/16 17:23, Alexandros Drymonitis wrote:

If you copy the [tanh] abstraction from purepd and make it a signal one,
doesn't that work? Then it's vanilla.


expr~ is available in all versions of Pd and has the same license.

It is probably slower than making a table, so doing what you said is a 
good idea for optimisation. Here is an abstraction that does what you 
describe:


https://github.com/chr15m/blockhead/blob/master/e_tanh.pd

Cheers,

Chris.

--
http://mccormick.cx/

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

Re: [PD] How's Pd limited?

[Alexandre Torres Porres]

2016-02-24 18:54 GMT-03:00 Brian Fay :

> The issue with blocking is that you don't have fine-grained control of an
> audio, process, right?
>

there are plenty techniques for having patches running with sample accuracy
- problem is that most pd and max objects miss this point, supercollider
seems to be more at it. For example, you can reset the phase of osc~ or
phasor~ via control messages only, if you could trigger it via an impulse
oscillator, you could easy have hard synced oscillators, but no... if you
want that, you need to make a more complicated patch, but there are ways
around it.
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] How's Pd limited?

[Alexandre Torres Porres]

i think there's noyhing in gen that you cant do in pd, it has a small set
of objects, but i guess the deal is that it, somehow, makes it more
efficient, that's all.

i've started studying max/msp recently, and i've found many things lacking
in it, more than i would've thought, by the way.

cheers

2016-02-24 16:39 GMT-03:00 peiman khosravi :

> My original point is that there is gen~ within maxmsp:
> https://www.youtube.com/watch?v=7iiekKzFstU
>
>
> *www.peimankhosravi.co.uk 
> 
> *
>
> On 24 February 2016 at 19:27, Matt Barber  wrote:
>
>> Are there any other DSP environments besides ChucK that don't block
>> audio? Last time I tried ChucK (2012?) its efficiency was still abysmal.
>> [block~ 1] definitely takes a hit, but it's usually possible to minimize
>> how much of the DSP chain is actually blocked at 1. I guess with Csound you
>> can specify a k-rate equal to the sample rate which is also effectively a
>> single sample block. I haven't ever used Csound in a real-time context, and
>> most of what I do with it compiles much more slowly than real time in any
>> case.
>>
>> On Wed, Feb 24, 2016 at 1:44 PM, peiman khosravi <
>> peimankhosr...@gmail.com> wrote:
>>
>>> You can do this with MSP's poly~ too but I'm guessing that the CPU costs
>>> are quite heavy. Moreover, there are operators in gen that are designed for
>>> low-level operations.
>>>
>>>
>>> *www.peimankhosravi.co.uk 
>>> 
>>> *
>>>
>>> On 24 February 2016 at 16:15, cyrille henry  wrote:
>>>


 Le 24/02/2016 16:50, peiman khosravi a écrit :

> One great advantage of maxmsp is gen, which gives you sample-level
> patching with the possibility of a one-sample delay.
>
>
 you can use [block~ 1 1 1] in a pd subpatch.

 cheers
 c


 P
>
> On Tuesday, February 23, 2016, Samuel Burt <
> composer.samuel.b...@gmail.com >
> wrote:
>
> David,
>
> One thing I attempted and couldn't find a solution for was the
> following, mostly owing to the limitation of interfacing with a 64 sample
> block size.
>
> I wanted to have a directory of hundreds of audio recordings. Each
> one would be a single wavelength from an interesting sound, like a bass
> clarinet, marimba, harpsichord, tambourine, etc. Each would begin and end
> at a zero crossing so you could chain them together to make complex
> timbres. They could be chained in sequence, randomized, or loaded in
> meta-data-matched chunks. I ran into a problem figuring out how to trigger
> the next sound based on the ending of the last sound in a sample accurate
> way. Sound file loading or even buffer playback triggering waits until the
> start of the next block size before it updates. If you have a waveform 
> that
> lasts 205 samples (64+64+64+13), you have a gap of 51 silent samples 
> before
> the next waveform would start. Not only do you not get the continuous 
> sound
> you want, this winds up creating a periodic pattern with a frequency of 
> 689
> Hz (44100/64).
>
> David, I like your idea "what (if anything) someone tried to do in
> Pd, but couldn't given its limitations". I think this could be a wonderful
> challenge if we could have a monthly thread like this where the best minds
> among us come up with solutions to some of the hardest conceptual
> challenges in Pd.
>
> I'm still struggling with loading dozens of files, audio dropouts,
> and other similar problems. Someone else expressed frustration about Pd's
> single-threaded status. I too have feared upgrading my computer based on
> the limitations of current multicore processors (although realistically I
> think we can all look at the "turbo-boost" level or whatever Intel calls 
> it
> to determine where our processor might run with a demanding patch. I
> understand the fact that you can't run your audio process on multiple
> cores, because it is a linear process. It would be great if the GUI could
> run on a second core, a process that loads audio into memory could run on
> third core, while GEM could automatically run on a fourth core. I don't
> have any concept of how feasible that would be, though. Does the GUI in
> pd-l2orc run on a separate core?
>
> Sam
>
>
>
>
>
>
> Message: 4
> Date: Tue, 23 Feb 2016 09:01:06 -0800
> From: david medine  >
>
> One thing I'd be interested in knowing about is 

Re: [PD] How's Pd limited?

[Jonathan Wilkes via Pd-list]

> It sounds very difficult, but I imagine gen~ does something like that.
I don't think the payoff is big enough to justify the development, unless 
what gets compiled are good old signal and/or control object chains that 
everybody is already familiar with.
That's what happened with Javascript engines.  It's quite extraordinary 
to see what can be done in the browser be people who have no idea 
what V8 is doing under the hood.  At the same time the people 
who are experts are building high-quality frameworks in a few years 
that would have previously taken a decade to develop.  And I can play 
old arcade games inside my browser.  Everybody wins.
One the other hand, that's pretty damned complex and expensive 
development.  Outside of trivial cases like a chain of unary op signal 
objects with single connections, I have no idea how one would optimize 
Pd patches, much less on the fly.  But surely the first step is better 
realtime analysis tools, so we can quickly know where the bulk of the 
CPU time is spent.
 
-Jonathan

 

  

On Wednesday, February 24, 2016 6:18 PM, Brian Fay 
 wrote:
 

 The issue with blocking is that you don't have fine-grained control of an 
audio, process, right? If you want that level of fine-grained control, you 
either need to explicitly set the blocksize to 1 in your patch/sub-patch, or 
you need to actually dig into the C code for the externals and change the logic 
there (which requires you write C code, recompile things, restart Pd...).
Theoretically, there could be a way to swap out the code for an external while 
Pd is running, rather than restarting Pd. Still, you'd have to write C and pray 
that you didn't introduce some terrible bug.
But theoretically, instead of writing externals in C, couldn't we come up with 
a high-level representation of a Pd external in a visual programming 
environment similar to Pd? Then we could compile that down to an external, and 
actually use it in our Pd patch, without actually reloading Pd. It sounds very 
difficult, but I imagine gen~ does something like that.

For reference, I believe Extempore provides the ability to edit and replace a 
low-level audio process while the program is running (I'll have to rewatch some 
conference videos to confirm that). 
On Wed, Feb 24, 2016 at 3:41 PM, Matt Barber  wrote:

OK, now I'm having trouble even imagining how an unblocked audio model could 
possibly behave (at least, as David points out, in a real-time context).
On Wed, Feb 24, 2016 at 2:58 PM, David Medine  wrote:

  This doesn't answer Matt's question at all (apologies), but just as a 
clarification, ChucK does block audio. It's just that ChucK always blocks at 
the minimum size of 1 sample per block. 1 is still a block size though, and it 
still implies the same problems associated with order of operations, feedback, 
interpolating control input, and parallelization that a block size of 64 does. 
 
 Also, maybe this has already been pointed out on this thread, but block 1 is 
super slow because it means that you have to load all your DSP functions onto 
the CPU cache every 1/SR seconds instead of 64/SR seconds. Blocking by 64 buys 
a lot. Having a locally adjustable block size is a great feature (that ChucK 
lacks) because you can do it for special needs cases (like variable delay 
patches, for example).
 
 Anyway, in my opinion, the block thing isn't a limit to Pd, but a limit to 
real-time digital signal processing.
 
 
 On 2/24/2016 11:27 AM, Matt Barber wrote:
  
  Are there any other DSP environments besides ChucK that don't block audio? 
Last time I tried ChucK (2012?) its efficiency was still abysmal. [block~ 1] 
definitely takes a hit, but it's usually possible to minimize how much of the 
DSP chain is actually blocked at 1. I guess with Csound you can specify a 
k-rate equal to the sample rate which is also effectively a single sample 
block. I haven't ever used Csound in a real-time context, and most of what I do 
with it compiles much more slowly than real time in any case.  
 On Wed, Feb 24, 2016 at 1:44 PM, peiman khosravi  
wrote:
 
  You can do this with MSP's poly~ too but I'm guessing that the CPU costs are 
quite heavy. Moreover, there are operators in gen that are designed for 
low-level operations. 
   
  
  www.peimankhosravi.co.uk 
 On 24 February 2016 at 16:15, cyrille henry  wrote:
 

 
 Le 24/02/2016 16:50, peiman khosravi a écrit :
 
 One great advantage of maxmsp is gen, which gives you sample-level patching 
with the possibility of a one-sample delay.
 
 
 
 you can use [block~ 1 1 1] in a pd subpatch.
 
 cheers
 c
 
 
 
 P
 
 On Tuesday, February 23, 2016, Samuel Burt > wrote:
 
     David,
 
     One thing I attempted and couldn't find a solution for was the following, 
mostly owing to the limitation of interfacing with 

Re: [PD] How's Pd limited?

[Mikael at UL]

…only by your imagination…

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

Re: [PD] How's Pd limited?

[Matt Barber]

How fine-grained does it need to be? As long as all the parameters are
known at the beginning of the block, you have everything you need. As far
as human interaction is concerned, 64-sample blocks are extremely
fine-grained. The individual cycles of the pitches at the beginning of
Beethoven's 5th are coarser grained. For computer generated events, there
are ways to schedule events to begin in the middle of a block.

The idea of a kind of Pd JIT compiler is interesting, though.

On Wed, Feb 24, 2016 at 4:54 PM, Brian Fay  wrote:

> The issue with blocking is that you don't have fine-grained control of an
> audio, process, right? If you want that level of fine-grained control, you
> either need to explicitly set the blocksize to 1 in your patch/sub-patch,
> or you need to actually dig into the C code for the externals and change
> the logic there (which requires you write C code, recompile things, restart
> Pd...).
>
> Theoretically, there could be a way to swap out the code for an external
> while Pd is running, rather than restarting Pd. Still, you'd have to write
> C and pray that you didn't introduce some terrible bug.
>
> But theoretically, instead of writing externals in C, couldn't we come up
> with a high-level representation of a Pd external in a visual programming
> environment similar to Pd? Then we could compile that down to an external,
> and actually use it in our Pd patch, without actually reloading Pd. It
> sounds very difficult, but I imagine gen~ does something like that.
>
> For reference, I believe Extempore provides the ability to edit and
> replace a low-level audio process while the program is running (I'll have
> to rewatch some conference videos to confirm that).
>
> On Wed, Feb 24, 2016 at 3:41 PM, Matt Barber  wrote:
>
>> OK, now I'm having trouble even imagining how an unblocked audio model
>> could possibly behave (at least, as David points out, in a real-time
>> context).
>>
>> On Wed, Feb 24, 2016 at 2:58 PM, David Medine  wrote:
>>
>>> This doesn't answer Matt's question at all (apologies), but just as a
>>> clarification, ChucK *does *block audio. It's just that ChucK always
>>> blocks at the minimum size of 1 sample per block. 1 is still a block size
>>> though, and it still implies the same problems associated with order of
>>> operations, feedback, interpolating control input, and parallelization that
>>> a block size of 64 does.
>>>
>>> Also, maybe this has already been pointed out on this thread, but block
>>> 1 is super slow because it means that you have to load all your DSP
>>> functions onto the CPU cache every 1/SR seconds instead of 64/SR seconds.
>>> Blocking by 64 buys a lot. Having a locally adjustable block size is a
>>> great feature (that ChucK lacks) because you can do it for special needs
>>> cases (like variable delay patches, for example).
>>>
>>> Anyway, in my opinion, the block thing isn't a limit to Pd, but a limit
>>> to real-time digital signal processing.
>>>
>>>
>>>
>>> On 2/24/2016 11:27 AM, Matt Barber wrote:
>>>
>>> Are there any other DSP environments besides ChucK that don't block
>>> audio? Last time I tried ChucK (2012?) its efficiency was still abysmal.
>>> [block~ 1] definitely takes a hit, but it's usually possible to minimize
>>> how much of the DSP chain is actually blocked at 1. I guess with Csound you
>>> can specify a k-rate equal to the sample rate which is also effectively a
>>> single sample block. I haven't ever used Csound in a real-time context, and
>>> most of what I do with it compiles much more slowly than real time in any
>>> case.
>>>
>>> On Wed, Feb 24, 2016 at 1:44 PM, peiman khosravi <
>>> peimankhosr...@gmail.com> wrote:
>>>
 You can do this with MSP's poly~ too but I'm guessing that the CPU
 costs are quite heavy. Moreover, there are operators in gen that are
 designed for low-level operations.


 *www.peimankhosravi.co.uk  *

 On 24 February 2016 at 16:15, cyrille henry < 
 c...@chnry.net> wrote:

>
>
> Le 24/02/2016 16:50, peiman khosravi a écrit :
>
>> One great advantage of maxmsp is gen, which gives you sample-level
>> patching with the possibility of a one-sample delay.
>>
>>
> you can use [block~ 1 1 1] in a pd subpatch.
>
> cheers
> c
>
>
> P
>>
>> On Tuesday, February 23, 2016, Samuel Burt <
>> composer.samuel.b...@gmail.com >
>> wrote:
>>
>> David,
>>
>> One thing I attempted and couldn't find a solution for was the
>> following, mostly owing to the limitation of interfacing with a 64 sample
>> block size.
>>
>> I wanted to have a directory of hundreds of audio recordings.
>> Each one would be a single wavelength from an interesting sound, like a
>> bass clarinet, marimba, harpsichord, 

Re: [PD] How's Pd limited?

[Jonathan Wilkes via Pd-list]

Just poll every microsecond, and increment the counter by one microsecond.
If there's something scheduled for that microsecond, do it.
:)
 

On Wednesday, February 24, 2016 4:19 PM, Matt Barber  
wrote:
 

 OK, now I'm having trouble even imagining how an unblocked audio model could 
possibly behave (at least, as David points out, in a real-time context).
On Wed, Feb 24, 2016 at 2:58 PM, David Medine  wrote:

  This doesn't answer Matt's question at all (apologies), but just as a 
clarification, ChucK does block audio. It's just that ChucK always blocks at 
the minimum size of 1 sample per block. 1 is still a block size though, and it 
still implies the same problems associated with order of operations, feedback, 
interpolating control input, and parallelization that a block size of 64 does. 
 
 Also, maybe this has already been pointed out on this thread, but block 1 is 
super slow because it means that you have to load all your DSP functions onto 
the CPU cache every 1/SR seconds instead of 64/SR seconds. Blocking by 64 buys 
a lot. Having a locally adjustable block size is a great feature (that ChucK 
lacks) because you can do it for special needs cases (like variable delay 
patches, for example).
 
 Anyway, in my opinion, the block thing isn't a limit to Pd, but a limit to 
real-time digital signal processing.
 
 
 On 2/24/2016 11:27 AM, Matt Barber wrote:
  
  Are there any other DSP environments besides ChucK that don't block audio? 
Last time I tried ChucK (2012?) its efficiency was still abysmal. [block~ 1] 
definitely takes a hit, but it's usually possible to minimize how much of the 
DSP chain is actually blocked at 1. I guess with Csound you can specify a 
k-rate equal to the sample rate which is also effectively a single sample 
block. I haven't ever used Csound in a real-time context, and most of what I do 
with it compiles much more slowly than real time in any case.  
 On Wed, Feb 24, 2016 at 1:44 PM, peiman khosravi  
wrote:
 
  You can do this with MSP's poly~ too but I'm guessing that the CPU costs are 
quite heavy. Moreover, there are operators in gen that are designed for 
low-level operations. 
   
  
  www.peimankhosravi.co.uk 
 On 24 February 2016 at 16:15, cyrille henry  wrote:
 

 
 Le 24/02/2016 16:50, peiman khosravi a écrit :
 
 One great advantage of maxmsp is gen, which gives you sample-level patching 
with the possibility of a one-sample delay.
 
 
 
 you can use [block~ 1 1 1] in a pd subpatch.
 
 cheers
 c
 
 
 
 P
 
 On Tuesday, February 23, 2016, Samuel Burt > wrote:
 
     David,
 
     One thing I attempted and couldn't find a solution for was the following, 
mostly owing to the limitation of interfacing with a 64 sample block size.
 
     I wanted to have a directory of hundreds of audio recordings. Each one 
would be a single wavelength from an interesting sound, like a bass clarinet, 
marimba, harpsichord, tambourine, etc. Each would begin and end at a zero 
crossing so you could chain them together to make complex timbres. They could 
be chained in sequence, randomized, or loaded in  meta-data-matched chunks. I 
ran into a problem figuring out how to trigger the next sound based on the 
ending of the last sound in a sample accurate way. Sound file loading or even 
buffer playback triggering waits until  the start of the next block size before 
it updates. If you have a waveform that lasts 205 samples (64+64+64+13), you 
have a gap of 51 silent samples before the next waveform would start. Not only 
do you not get the continuous  sound you want, this winds up creating a 
periodic pattern with a frequency of 689 Hz (44100/64).
 
     David, I like your idea "what (if anything) someone tried to do in Pd, but 
couldn't given its limitations". I think this  could be a wonderful challenge 
if we could have a monthly thread like this where the best minds among us come 
up with solutions to some of the hardest conceptual challenges in Pd.
 
     I'm still struggling with loading dozens of files, audio dropouts, and 
other similar problems. Someone else expressed frustration about Pd's 
single-threaded status. I too have feared upgrading my computer based on the 
limitations of current multicore processors (although realistically I think we 
can all look at the "turbo-boost" level or whatever  Intel calls it to 
determine where our processor might run with a demanding patch. I understand 
the fact that you can't run your audio process on multiple cores, because it is 
a linear process. It would be great if the GUI  could run on a second core, a 
process that loads audio into memory could run on third core, while GEM could 
automatically run on a fourth core. I don't have any concept of how feasible 
that would be, though. Does the GUI  in pd-l2orc run on a separate core?
 
     Sam
 
 
 
 
 
 
         

Re: [PD] How's Pd limited?

[Brian Fay]

The issue with blocking is that you don't have fine-grained control of an
audio, process, right? If you want that level of fine-grained control, you
either need to explicitly set the blocksize to 1 in your patch/sub-patch,
or you need to actually dig into the C code for the externals and change
the logic there (which requires you write C code, recompile things, restart
Pd...).

Theoretically, there could be a way to swap out the code for an external
while Pd is running, rather than restarting Pd. Still, you'd have to write
C and pray that you didn't introduce some terrible bug.

But theoretically, instead of writing externals in C, couldn't we come up
with a high-level representation of a Pd external in a visual programming
environment similar to Pd? Then we could compile that down to an external,
and actually use it in our Pd patch, without actually reloading Pd. It
sounds very difficult, but I imagine gen~ does something like that.

For reference, I believe Extempore provides the ability to edit and replace
a low-level audio process while the program is running (I'll have to
rewatch some conference videos to confirm that).

On Wed, Feb 24, 2016 at 3:41 PM, Matt Barber  wrote:

> OK, now I'm having trouble even imagining how an unblocked audio model
> could possibly behave (at least, as David points out, in a real-time
> context).
>
> On Wed, Feb 24, 2016 at 2:58 PM, David Medine  wrote:
>
>> This doesn't answer Matt's question at all (apologies), but just as a
>> clarification, ChucK *does *block audio. It's just that ChucK always
>> blocks at the minimum size of 1 sample per block. 1 is still a block size
>> though, and it still implies the same problems associated with order of
>> operations, feedback, interpolating control input, and parallelization that
>> a block size of 64 does.
>>
>> Also, maybe this has already been pointed out on this thread, but block 1
>> is super slow because it means that you have to load all your DSP functions
>> onto the CPU cache every 1/SR seconds instead of 64/SR seconds. Blocking by
>> 64 buys a lot. Having a locally adjustable block size is a great feature
>> (that ChucK lacks) because you can do it for special needs cases (like
>> variable delay patches, for example).
>>
>> Anyway, in my opinion, the block thing isn't a limit to Pd, but a limit
>> to real-time digital signal processing.
>>
>>
>>
>> On 2/24/2016 11:27 AM, Matt Barber wrote:
>>
>> Are there any other DSP environments besides ChucK that don't block
>> audio? Last time I tried ChucK (2012?) its efficiency was still abysmal.
>> [block~ 1] definitely takes a hit, but it's usually possible to minimize
>> how much of the DSP chain is actually blocked at 1. I guess with Csound you
>> can specify a k-rate equal to the sample rate which is also effectively a
>> single sample block. I haven't ever used Csound in a real-time context, and
>> most of what I do with it compiles much more slowly than real time in any
>> case.
>>
>> On Wed, Feb 24, 2016 at 1:44 PM, peiman khosravi <
>> peimankhosr...@gmail.com> wrote:
>>
>>> You can do this with MSP's poly~ too but I'm guessing that the CPU costs
>>> are quite heavy. Moreover, there are operators in gen that are designed for
>>> low-level operations.
>>>
>>>
>>> *www.peimankhosravi.co.uk  *
>>>
>>> On 24 February 2016 at 16:15, cyrille henry < c...@chnry.net
>>> > wrote:
>>>


 Le 24/02/2016 16:50, peiman khosravi a écrit :

> One great advantage of maxmsp is gen, which gives you sample-level
> patching with the possibility of a one-sample delay.
>
>
 you can use [block~ 1 1 1] in a pd subpatch.

 cheers
 c


 P
>
> On Tuesday, February 23, 2016, Samuel Burt <
> composer.samuel.b...@gmail.com >
> wrote:
>
> David,
>
> One thing I attempted and couldn't find a solution for was the
> following, mostly owing to the limitation of interfacing with a 64 sample
> block size.
>
> I wanted to have a directory of hundreds of audio recordings. Each
> one would be a single wavelength from an interesting sound, like a bass
> clarinet, marimba, harpsichord, tambourine, etc. Each would begin and end
> at a zero crossing so you could chain them together to make complex
> timbres. They could be chained in sequence, randomized, or loaded in
> meta-data-matched chunks. I ran into a problem figuring out how to trigger
> the next sound based on the ending of the last sound in a sample accurate
> way. Sound file loading or even buffer playback triggering waits until the
> start of the next block size before it updates. If you have a waveform 
> that
> lasts 205 samples (64+64+64+13), you have a gap of 51 silent samples 
> before
> the next waveform would start. Not only do you not get the continuous 

Re: [PD] How's Pd limited?

[Matt Barber]

OK, now I'm having trouble even imagining how an unblocked audio model
could possibly behave (at least, as David points out, in a real-time
context).

On Wed, Feb 24, 2016 at 2:58 PM, David Medine  wrote:

> This doesn't answer Matt's question at all (apologies), but just as a
> clarification, ChucK *does *block audio. It's just that ChucK always
> blocks at the minimum size of 1 sample per block. 1 is still a block size
> though, and it still implies the same problems associated with order of
> operations, feedback, interpolating control input, and parallelization that
> a block size of 64 does.
>
> Also, maybe this has already been pointed out on this thread, but block 1
> is super slow because it means that you have to load all your DSP functions
> onto the CPU cache every 1/SR seconds instead of 64/SR seconds. Blocking by
> 64 buys a lot. Having a locally adjustable block size is a great feature
> (that ChucK lacks) because you can do it for special needs cases (like
> variable delay patches, for example).
>
> Anyway, in my opinion, the block thing isn't a limit to Pd, but a limit to
> real-time digital signal processing.
>
>
>
> On 2/24/2016 11:27 AM, Matt Barber wrote:
>
> Are there any other DSP environments besides ChucK that don't block audio?
> Last time I tried ChucK (2012?) its efficiency was still abysmal. [block~
> 1] definitely takes a hit, but it's usually possible to minimize how much
> of the DSP chain is actually blocked at 1. I guess with Csound you can
> specify a k-rate equal to the sample rate which is also effectively a
> single sample block. I haven't ever used Csound in a real-time context, and
> most of what I do with it compiles much more slowly than real time in any
> case.
>
> On Wed, Feb 24, 2016 at 1:44 PM, peiman khosravi  > wrote:
>
>> You can do this with MSP's poly~ too but I'm guessing that the CPU costs
>> are quite heavy. Moreover, there are operators in gen that are designed for
>> low-level operations.
>>
>>
>> *www.peimankhosravi.co.uk  *
>>
>> On 24 February 2016 at 16:15, cyrille henry < c...@chnry.net>
>> wrote:
>>
>>>
>>>
>>> Le 24/02/2016 16:50, peiman khosravi a écrit :
>>>
 One great advantage of maxmsp is gen, which gives you sample-level
 patching with the possibility of a one-sample delay.


>>> you can use [block~ 1 1 1] in a pd subpatch.
>>>
>>> cheers
>>> c
>>>
>>>
>>> P

 On Tuesday, February 23, 2016, Samuel Burt <
 composer.samuel.b...@gmail.com >
 wrote:

 David,

 One thing I attempted and couldn't find a solution for was the
 following, mostly owing to the limitation of interfacing with a 64 sample
 block size.

 I wanted to have a directory of hundreds of audio recordings. Each
 one would be a single wavelength from an interesting sound, like a bass
 clarinet, marimba, harpsichord, tambourine, etc. Each would begin and end
 at a zero crossing so you could chain them together to make complex
 timbres. They could be chained in sequence, randomized, or loaded in
 meta-data-matched chunks. I ran into a problem figuring out how to trigger
 the next sound based on the ending of the last sound in a sample accurate
 way. Sound file loading or even buffer playback triggering waits until the
 start of the next block size before it updates. If you have a waveform that
 lasts 205 samples (64+64+64+13), you have a gap of 51 silent samples before
 the next waveform would start. Not only do you not get the continuous sound
 you want, this winds up creating a periodic pattern with a frequency of 689
 Hz (44100/64).

 David, I like your idea "what (if anything) someone tried to do in
 Pd, but couldn't given its limitations". I think this could be a wonderful
 challenge if we could have a monthly thread like this where the best minds
 among us come up with solutions to some of the hardest conceptual
 challenges in Pd.

 I'm still struggling with loading dozens of files, audio dropouts,
 and other similar problems. Someone else expressed frustration about Pd's
 single-threaded status. I too have feared upgrading my computer based on
 the limitations of current multicore processors (although realistically I
 think we can all look at the "turbo-boost" level or whatever Intel calls it
 to determine where our processor might run with a demanding patch. I
 understand the fact that you can't run your audio process on multiple
 cores, because it is a linear process. It would be great if the GUI could
 run on a second core, a process that loads audio into memory could run on
 third core, while GEM could automatically run on a fourth core. I don't
 have any concept of how feasible that would be, though. Does the GUI in
 pd-l2orc run on a 

Re: [PD] How's Pd limited?

[David Medine]

This doesn't answer Matt's question at all (apologies), but just as a 
clarification, ChucK /does /block audio. It's just that ChucK always 
blocks at the minimum size of 1 sample per block. 1 is still a block 
size though, and it still implies the same problems associated with 
order of operations, feedback, interpolating control input, and 
parallelization that a block size of 64 does.


Also, maybe this has already been pointed out on this thread, but block 
1 is super slow because it means that you have to load all your DSP 
functions onto the CPU cache every 1/SR seconds instead of 64/SR 
seconds. Blocking by 64 buys a lot. Having a locally adjustable block 
size is a great feature (that ChucK lacks) because you can do it for 
special needs cases (like variable delay patches, for example).


Anyway, in my opinion, the block thing isn't a limit to Pd, but a limit 
to real-time digital signal processing.



On 2/24/2016 11:27 AM, Matt Barber wrote:
Are there any other DSP environments besides ChucK that don't block 
audio? Last time I tried ChucK (2012?) its efficiency was still 
abysmal. [block~ 1] definitely takes a hit, but it's usually possible 
to minimize how much of the DSP chain is actually blocked at 1. I 
guess with Csound you can specify a k-rate equal to the sample rate 
which is also effectively a single sample block. I haven't ever used 
Csound in a real-time context, and most of what I do with it compiles 
much more slowly than real time in any case.


On Wed, Feb 24, 2016 at 1:44 PM, peiman khosravi 
> wrote:


You can do this with MSP's poly~ too but I'm guessing that the CPU
costs are quite heavy. Moreover, there are operators in gen that
are designed for low-level operations.


*www.peimankhosravi.co.uk  *

On 24 February 2016 at 16:15, cyrille henry > wrote:



Le 24/02/2016 16:50, peiman khosravi a écrit :

One great advantage of maxmsp is gen, which gives you
sample-level patching with the possibility of a one-sample
delay.


you can use [block~ 1 1 1] in a pd subpatch.

cheers
c


P

On Tuesday, February 23, 2016, Samuel Burt

>> wrote:

David,

One thing I attempted and couldn't find a solution for
was the following, mostly owing to the limitation of
interfacing with a 64 sample block size.

I wanted to have a directory of hundreds of audio
recordings. Each one would be a single wavelength from an
interesting sound, like a bass clarinet, marimba,
harpsichord, tambourine, etc. Each would begin and end at
a zero crossing so you could chain them together to make
complex timbres. They could be chained in sequence,
randomized, or loaded in meta-data-matched chunks. I ran
into a problem figuring out how to trigger the next sound
based on the ending of the last sound in a sample accurate
way. Sound file loading or even buffer playback triggering
waits until the start of the next block size before it
updates. If you have a waveform that lasts 205 samples
(64+64+64+13), you have a gap of 51 silent samples before
the next waveform would start. Not only do you not get the
continuous sound you want, this winds up creating a
periodic pattern with a frequency of 689 Hz (44100/64).

David, I like your idea "what (if anything) someone
tried to do in Pd, but couldn't given its limitations". I
think this could be a wonderful challenge if we could have
a monthly thread like this where the best minds among us
come up with solutions to some of the hardest conceptual
challenges in Pd.

I'm still struggling with loading dozens of files,
audio dropouts, and other similar problems. Someone else
expressed frustration about Pd's single-threaded status. I
too have feared upgrading my computer based on the
limitations of current multicore processors (although
realistically I think we can all look at the "turbo-boost"
level or whatever Intel calls it to determine where our
processor might run with a demanding patch. I understand
the fact that you can't run your audio process on multiple
cores, because it is a linear process. It would be great
if the GUI could run on a second core, a process that
loads 

Re: [PD] How's Pd limited?

[Lucas Cordiviola]

You can do somthing like MSP poly~ with Pd poly and switch~ or route and 
switch~.
The (64+64+64+13) example can be corrected by knowing when its going to end, ie 
sheduling the next one when that one is fired, as long as its longer than 1 
block (64samples). You need to store the name of the file with the file lenght. 
then  somthing with the del object. better with alternating 2 players (readsf~, 
table or other).
Mensaje telepatico asistido por maquinas.

Date: Wed, 24 Feb 2016 18:44:00 +
From: peimankhosr...@gmail.com
To: c...@chnry.net
CC: pd-list@lists.iem.at
Subject: Re: [PD] How's Pd limited?

You can do this with MSP's poly~ too but I'm guessing that the CPU costs are 
quite heavy. Moreover, there are operators in gen that are designed for 
low-level operations. 

www.peimankhosravi.co.uk 

On 24 February 2016 at 16:15, cyrille henry <c...@chnry.net> wrote:




Le 24/02/2016 16:50, peiman khosravi a écrit :


One great advantage of maxmsp is gen, which gives you sample-level patching 
with the possibility of a one-sample delay.






you can use [block~ 1 1 1] in a pd subpatch.



cheers

c






P



On Tuesday, February 23, 2016, Samuel Burt <composer.samuel.b...@gmail.com 
<mailto:composer.samuel.b...@gmail.com>> wrote:



David,



One thing I attempted and couldn't find a solution for was the following, 
mostly owing to the limitation of interfacing with a 64 sample block size.



I wanted to have a directory of hundreds of audio recordings. Each one 
would be a single wavelength from an interesting sound, like a bass clarinet, 
marimba, harpsichord, tambourine, etc. Each would begin and end at a zero 
crossing so you could chain them together to make complex timbres. They could 
be chained in sequence, randomized, or loaded in meta-data-matched chunks. I 
ran into a problem figuring out how to trigger the next sound based on the 
ending of the last sound in a sample accurate way. Sound file loading or even 
buffer playback triggering waits until the start of the next block size before 
it updates. If you have a waveform that lasts 205 samples (64+64+64+13), you 
have a gap of 51 silent samples before the next waveform would start. Not only 
do you not get the continuous sound you want, this winds up creating a periodic 
pattern with a frequency of 689 Hz (44100/64).



David, I like your idea "what (if anything) someone tried to do in Pd, but 
couldn't given its limitations". I think this could be a wonderful challenge if 
we could have a monthly thread like this where the best minds among us come up 
with solutions to some of the hardest conceptual challenges in Pd.



I'm still struggling with loading dozens of files, audio dropouts, and 
other similar problems. Someone else expressed frustration about Pd's 
single-threaded status. I too have feared upgrading my computer based on the 
limitations of current multicore processors (although realistically I think we 
can all look at the "turbo-boost" level or whatever Intel calls it to determine 
where our processor might run with a demanding patch. I understand the fact 
that you can't run your audio process on multiple cores, because it is a linear 
process. It would be great if the GUI could run on a second core, a process 
that loads audio into memory could run on third core, while GEM could 
automatically run on a fourth core. I don't have any concept of how feasible 
that would be, though. Does the GUI in pd-l2orc run on a separate core?



Sam













Message: 4

Date: Tue, 23 Feb 2016 09:01:06 -0800

From: david medine <dmed...@ucsd.edu 
<javascript:_e(%7B%7D,'cvml','dmed...@ucsd.edu');>>



One thing I'd be interested in knowing about is what (if anything)

someone tried to do in Pd, but couldn't given its limitations (apart

from look/feel/convenience issues).







--



*www.peimankhosravi.co.uk <http://www.peimankhosravi.co.uk> 
<http://peimankhosravi.co.uk/miscposts.rss><http://spectralkimia.wordpress.com/>*







___

Pd-list@lists.iem.at mailing list

UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list






___

Pd-list@lists.iem.at mailing list

UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list




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

Re: [PD] How's Pd limited?

[Matt Barber]

Are there any other DSP environments besides ChucK that don't block audio?
Last time I tried ChucK (2012?) its efficiency was still abysmal. [block~
1] definitely takes a hit, but it's usually possible to minimize how much
of the DSP chain is actually blocked at 1. I guess with Csound you can
specify a k-rate equal to the sample rate which is also effectively a
single sample block. I haven't ever used Csound in a real-time context, and
most of what I do with it compiles much more slowly than real time in any
case.

On Wed, Feb 24, 2016 at 1:44 PM, peiman khosravi 
wrote:

> You can do this with MSP's poly~ too but I'm guessing that the CPU costs
> are quite heavy. Moreover, there are operators in gen that are designed for
> low-level operations.
>
>
> *www.peimankhosravi.co.uk 
> 
> *
>
> On 24 February 2016 at 16:15, cyrille henry  wrote:
>
>>
>>
>> Le 24/02/2016 16:50, peiman khosravi a écrit :
>>
>>> One great advantage of maxmsp is gen, which gives you sample-level
>>> patching with the possibility of a one-sample delay.
>>>
>>>
>> you can use [block~ 1 1 1] in a pd subpatch.
>>
>> cheers
>> c
>>
>>
>> P
>>>
>>> On Tuesday, February 23, 2016, Samuel Burt <
>>> composer.samuel.b...@gmail.com >
>>> wrote:
>>>
>>> David,
>>>
>>> One thing I attempted and couldn't find a solution for was the
>>> following, mostly owing to the limitation of interfacing with a 64 sample
>>> block size.
>>>
>>> I wanted to have a directory of hundreds of audio recordings. Each
>>> one would be a single wavelength from an interesting sound, like a bass
>>> clarinet, marimba, harpsichord, tambourine, etc. Each would begin and end
>>> at a zero crossing so you could chain them together to make complex
>>> timbres. They could be chained in sequence, randomized, or loaded in
>>> meta-data-matched chunks. I ran into a problem figuring out how to trigger
>>> the next sound based on the ending of the last sound in a sample accurate
>>> way. Sound file loading or even buffer playback triggering waits until the
>>> start of the next block size before it updates. If you have a waveform that
>>> lasts 205 samples (64+64+64+13), you have a gap of 51 silent samples before
>>> the next waveform would start. Not only do you not get the continuous sound
>>> you want, this winds up creating a periodic pattern with a frequency of 689
>>> Hz (44100/64).
>>>
>>> David, I like your idea "what (if anything) someone tried to do in
>>> Pd, but couldn't given its limitations". I think this could be a wonderful
>>> challenge if we could have a monthly thread like this where the best minds
>>> among us come up with solutions to some of the hardest conceptual
>>> challenges in Pd.
>>>
>>> I'm still struggling with loading dozens of files, audio dropouts,
>>> and other similar problems. Someone else expressed frustration about Pd's
>>> single-threaded status. I too have feared upgrading my computer based on
>>> the limitations of current multicore processors (although realistically I
>>> think we can all look at the "turbo-boost" level or whatever Intel calls it
>>> to determine where our processor might run with a demanding patch. I
>>> understand the fact that you can't run your audio process on multiple
>>> cores, because it is a linear process. It would be great if the GUI could
>>> run on a second core, a process that loads audio into memory could run on
>>> third core, while GEM could automatically run on a fourth core. I don't
>>> have any concept of how feasible that would be, though. Does the GUI in
>>> pd-l2orc run on a separate core?
>>>
>>> Sam
>>>
>>>
>>>
>>>
>>>
>>>
>>> Message: 4
>>> Date: Tue, 23 Feb 2016 09:01:06 -0800
>>> From: david medine >> >
>>>
>>> One thing I'd be interested in knowing about is what (if
>>> anything)
>>> someone tried to do in Pd, but couldn't given its limitations
>>> (apart
>>> from look/feel/convenience issues).
>>>
>>>
>>>
>>> --
>>>
>>> *www.peimankhosravi.co.uk  <
>>> http://peimankhosravi.co.uk/miscposts.rss><
>>> http://spectralkimia.wordpress.com/>*
>>>
>>>
>>>
>>> ___
>>> Pd-list@lists.iem.at mailing list
>>> UNSUBSCRIBE and account-management ->
>>> http://lists.puredata.info/listinfo/pd-list
>>>
>>>
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
___

Re: [PD] How's Pd limited?

[peiman khosravi]

You can do this with MSP's poly~ too but I'm guessing that the CPU costs
are quite heavy. Moreover, there are operators in gen that are designed for
low-level operations.


*www.peimankhosravi.co.uk 

*

On 24 February 2016 at 16:15, cyrille henry  wrote:

>
>
> Le 24/02/2016 16:50, peiman khosravi a écrit :
>
>> One great advantage of maxmsp is gen, which gives you sample-level
>> patching with the possibility of a one-sample delay.
>>
>>
> you can use [block~ 1 1 1] in a pd subpatch.
>
> cheers
> c
>
>
> P
>>
>> On Tuesday, February 23, 2016, Samuel Burt <
>> composer.samuel.b...@gmail.com >
>> wrote:
>>
>> David,
>>
>> One thing I attempted and couldn't find a solution for was the
>> following, mostly owing to the limitation of interfacing with a 64 sample
>> block size.
>>
>> I wanted to have a directory of hundreds of audio recordings. Each
>> one would be a single wavelength from an interesting sound, like a bass
>> clarinet, marimba, harpsichord, tambourine, etc. Each would begin and end
>> at a zero crossing so you could chain them together to make complex
>> timbres. They could be chained in sequence, randomized, or loaded in
>> meta-data-matched chunks. I ran into a problem figuring out how to trigger
>> the next sound based on the ending of the last sound in a sample accurate
>> way. Sound file loading or even buffer playback triggering waits until the
>> start of the next block size before it updates. If you have a waveform that
>> lasts 205 samples (64+64+64+13), you have a gap of 51 silent samples before
>> the next waveform would start. Not only do you not get the continuous sound
>> you want, this winds up creating a periodic pattern with a frequency of 689
>> Hz (44100/64).
>>
>> David, I like your idea "what (if anything) someone tried to do in
>> Pd, but couldn't given its limitations". I think this could be a wonderful
>> challenge if we could have a monthly thread like this where the best minds
>> among us come up with solutions to some of the hardest conceptual
>> challenges in Pd.
>>
>> I'm still struggling with loading dozens of files, audio dropouts,
>> and other similar problems. Someone else expressed frustration about Pd's
>> single-threaded status. I too have feared upgrading my computer based on
>> the limitations of current multicore processors (although realistically I
>> think we can all look at the "turbo-boost" level or whatever Intel calls it
>> to determine where our processor might run with a demanding patch. I
>> understand the fact that you can't run your audio process on multiple
>> cores, because it is a linear process. It would be great if the GUI could
>> run on a second core, a process that loads audio into memory could run on
>> third core, while GEM could automatically run on a fourth core. I don't
>> have any concept of how feasible that would be, though. Does the GUI in
>> pd-l2orc run on a separate core?
>>
>> Sam
>>
>>
>>
>>
>>
>>
>> Message: 4
>> Date: Tue, 23 Feb 2016 09:01:06 -0800
>> From: david medine > >
>>
>> One thing I'd be interested in knowing about is what (if anything)
>> someone tried to do in Pd, but couldn't given its limitations
>> (apart
>> from look/feel/convenience issues).
>>
>>
>>
>> --
>>
>> *www.peimankhosravi.co.uk  <
>> http://peimankhosravi.co.uk/miscposts.rss><
>> http://spectralkimia.wordpress.com/>*
>>
>>
>>
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] How's Pd limited?

[Jonathan Wilkes via Pd-list]

I think one of the big limitations is a difficulty in turning "hot" code "cool".
For example, suppose the [hungry~] abstraction is at the heart of your patch 
but it consumes a lot of CPU.  What do you do?
Typically the process involves only two steps:1. make esoteric changes that 
marginally decrease the CPU load2. give up and port [hungry~] to a C or C++ 
external
#1 decreases readability, and #2 decreases portability (and hopefully 
readability as well).

Parallelization may be a means to address this, but it is a means and not an 
end.  In any case the first place to start is 
to profile CPU usage and patch performance, as well as signal and object 
performance within the patch.  Pd needs tools 
to accurately measure which classes and abstractions are responsible when a 
patch runs hot.

Desiredata apparently added some functionality to do that but it was apparently 
buggy and didn't get a lot of testing.  Anyhow, 
these tools are crucial to a sensible discussion of parallelization-- without 
them we can only measure object performance with 
very blunt tools.
-Jonathan
   

 On Wednesday, February 24, 2016 10:53 AM, peiman khosravi 
 wrote:
 

 One great advantage of maxmsp is gen, which gives you sample-level patching 
with the possibility of a one-sample delay.
P

On Tuesday, February 23, 2016, Samuel Burt  
wrote:

David,
One thing I attempted and couldn't find a solution for was the following, 
mostly owing to the limitation of interfacing with a 64 sample block size.
I wanted to have a directory of hundreds of audio recordings. Each one would be 
a single wavelength from an interesting sound, like a bass clarinet, marimba, 
harpsichord, tambourine, etc. Each would begin and end at a zero crossing so 
you could chain them together to make complex timbres. They could be chained in 
sequence, randomized, or loaded in meta-data-matched chunks. I ran into a 
problem figuring out how to trigger the next sound based on the ending of the 
last sound in a sample accurate way. Sound file loading or even buffer playback 
triggering waits until the start of the next block size before it updates. If 
you have a waveform that lasts 205 samples (64+64+64+13), you have a gap of 51 
silent samples before the next waveform would start. Not only do you not get 
the continuous sound you want, this winds up creating a periodic pattern with a 
frequency of 689 Hz (44100/64).
David, I like your idea "what (if anything) someone tried to do in Pd, but 
couldn't given its limitations". I think this could be a wonderful challenge if 
we could have a monthly thread like this where the best minds among us come up 
with solutions to some of the hardest conceptual challenges in Pd.
I'm still struggling with loading dozens of files, audio dropouts, and other 
similar problems. Someone else expressed frustration about Pd's single-threaded 
status. I too have feared upgrading my computer based on the limitations of 
current multicore processors (although realistically I think we can all look at 
the "turbo-boost" level or whatever Intel calls it to determine where our 
processor might run with a demanding patch. I understand the fact that you 
can't run your audio process on multiple cores, because it is a linear process. 
It would be great if the GUI could run on a second core, a process that loads 
audio into memory could run on third core, while GEM could automatically run on 
a fourth core. I don't have any concept of how feasible that would be, though. 
Does the GUI in pd-l2orc run on a separate core?
Sam






Message: 4
Date: Tue, 23 Feb 2016 09:01:06 -0800
From: david medine 

One thing I'd be interested in knowing about is what (if anything)
someone tried to do in Pd, but couldn't given its limitations (apart
from look/feel/convenience issues).





-- 

www.peimankhosravi.co.uk 

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


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

Re: [PD] How's Pd limited?

[cyrille henry]

Le 24/02/2016 16:50, peiman khosravi a écrit :

One great advantage of maxmsp is gen, which gives you sample-level patching 
with the possibility of a one-sample delay.



you can use [block~ 1 1 1] in a pd subpatch.

cheers
c



P

On Tuesday, February 23, 2016, Samuel Burt > wrote:

David,

One thing I attempted and couldn't find a solution for was the following, 
mostly owing to the limitation of interfacing with a 64 sample block size.

I wanted to have a directory of hundreds of audio recordings. Each one 
would be a single wavelength from an interesting sound, like a bass clarinet, 
marimba, harpsichord, tambourine, etc. Each would begin and end at a zero 
crossing so you could chain them together to make complex timbres. They could 
be chained in sequence, randomized, or loaded in meta-data-matched chunks. I 
ran into a problem figuring out how to trigger the next sound based on the 
ending of the last sound in a sample accurate way. Sound file loading or even 
buffer playback triggering waits until the start of the next block size before 
it updates. If you have a waveform that lasts 205 samples (64+64+64+13), you 
have a gap of 51 silent samples before the next waveform would start. Not only 
do you not get the continuous sound you want, this winds up creating a periodic 
pattern with a frequency of 689 Hz (44100/64).

David, I like your idea "what (if anything) someone tried to do in Pd, but 
couldn't given its limitations". I think this could be a wonderful challenge if we 
could have a monthly thread like this where the best minds among us come up with 
solutions to some of the hardest conceptual challenges in Pd.

I'm still struggling with loading dozens of files, audio dropouts, and other similar 
problems. Someone else expressed frustration about Pd's single-threaded status. I too 
have feared upgrading my computer based on the limitations of current multicore 
processors (although realistically I think we can all look at the "turbo-boost" 
level or whatever Intel calls it to determine where our processor might run with a 
demanding patch. I understand the fact that you can't run your audio process on multiple 
cores, because it is a linear process. It would be great if the GUI could run on a second 
core, a process that loads audio into memory could run on third core, while GEM could 
automatically run on a fourth core. I don't have any concept of how feasible that would 
be, though. Does the GUI in pd-l2orc run on a separate core?

Sam






Message: 4
Date: Tue, 23 Feb 2016 09:01:06 -0800
From: david medine >

One thing I'd be interested in knowing about is what (if anything)
someone tried to do in Pd, but couldn't given its limitations (apart
from look/feel/convenience issues).



--

*www.peimankhosravi.co.uk  
*



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



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

Re: [PD] How's Pd limited?

[peiman khosravi]

One great advantage of maxmsp is gen, which gives you sample-level patching
with the possibility of a one-sample delay.

P

On Tuesday, February 23, 2016, Samuel Burt 
wrote:

> David,
>
> One thing I attempted and couldn't find a solution for was the following,
> mostly owing to the limitation of interfacing with a 64 sample block size.
>
> I wanted to have a directory of hundreds of audio recordings. Each one
> would be a single wavelength from an interesting sound, like a bass
> clarinet, marimba, harpsichord, tambourine, etc. Each would begin and end
> at a zero crossing so you could chain them together to make complex
> timbres. They could be chained in sequence, randomized, or loaded in
> meta-data-matched chunks. I ran into a problem figuring out how to trigger
> the next sound based on the ending of the last sound in a sample accurate
> way. Sound file loading or even buffer playback triggering waits until the
> start of the next block size before it updates. If you have a waveform that
> lasts 205 samples (64+64+64+13), you have a gap of 51 silent samples before
> the next waveform would start. Not only do you not get the continuous sound
> you want, this winds up creating a periodic pattern with a frequency of 689
> Hz (44100/64).
>
> David, I like your idea "what (if anything) someone tried to do in Pd, but
> couldn't given its limitations". I think this could be a wonderful
> challenge if we could have a monthly thread like this where the best minds
> among us come up with solutions to some of the hardest conceptual
> challenges in Pd.
>
> I'm still struggling with loading dozens of files, audio dropouts, and
> other similar problems. Someone else expressed frustration about Pd's
> single-threaded status. I too have feared upgrading my computer based on
> the limitations of current multicore processors (although realistically I
> think we can all look at the "turbo-boost" level or whatever Intel calls it
> to determine where our processor might run with a demanding patch. I
> understand the fact that you can't run your audio process on multiple
> cores, because it is a linear process. It would be great if the GUI could
> run on a second core, a process that loads audio into memory could run on
> third core, while GEM could automatically run on a fourth core. I don't
> have any concept of how feasible that would be, though. Does the GUI in
> pd-l2orc run on a separate core?
>
> Sam
>
>
>
>
>
>
>> Message: 4
>> Date: Tue, 23 Feb 2016 09:01:06 -0800
>> From: david medine > >
>>
>> One thing I'd be interested in knowing about is what (if anything)
>> someone tried to do in Pd, but couldn't given its limitations (apart
>> from look/feel/convenience issues).
>>
>>

-- 

*www.peimankhosravi.co.uk 

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

Re: [PD] How's Pd limited?

[martin brinkmann]

maybe this is also a matter of convenience: i'd rather have the
dsp-framework automagically divide and distribute my program
to the available resources than to care for it myself. while it
is for example ok to put each complex voice of a synth in an extra
pd~ to make optimum use of the few cores, i'd rather not want
to spend much time thinking about grouping functinality into
(lots of) pd~ objects for a huge amount of cores.

one possibility would be to generally encapsulate any small part
of a patch into its own pd~ object and let the os do the work.
but i think this is not very convenient and would create a
massive and unnecessary overhead.

i don't know of any (audio-)examples where this problem is handled in
an elegant way though: afaik max has the same problem, reaktor is
single-threaded too, and most daws do something like "use one thread per
track"...


On 23/02/16 23:45, David Medine wrote:
> I think we all need to learn more about multi-threading if we want to
> run real-time, modular, digital signal processing algorithms on
> multi-core machines. I, for one, can not think of any general, robust
> way to do this. In that sense, Pd's adherence to single threading is
> actually a very elegant solution to the problem.
> 
> On 2/23/2016 12:25 PM, martin brinkmann wrote:
>> On 22/02/16 02:49, Matti Viljamaa wrote:
>>
>>> How do you think Pure Data is limited?
>> for me the only real and important (i can think of at the
>> moment) limitation is the block-based audio processing.
>> to me this seems quite unnatural and inconvenient when dealing with
>> digital audio. it kept me for a couple of years from using pd, though it
>> is only a 'showstopper' in rather few cases, i found out.
>> feedback in large/complex patches for example, since it
>> is not very practical (or possible at all) to re-block
>> everything to 1...
>>
>> what i tried but couldn't (yet): build a decent piano-roll
>> editor (vanilla).
>>
>> and i believe too, pd has to 'learn' better multithreading to run
>> adequately on our future machines with hundreds or even thousands of
>> arm-cores...
>>
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
> 
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list


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

Re: [PD] How's Pd limited?

[Jack]

Hello,

Le 24/02/2016 00:19, Matt Barber a écrit :
> Can anyone explain more why [pd~] doesn't fulfill the desire for
> parallel processing, and maybe provide an example of something outside
> of Pd that does? I don't feel like I have a great handle on the design.
> As Jonathan said, it seems like Pd's determinism constraint is a big
> hurdle to clear, though it's already relaxed a bit with netsend/receive.
> What are the main differences between running an instance of Pd as a
> [pd~] slave to another instance, and running two instances that
> communicate via netsend/receive and jack?

I think, the main difference is :
- with [pd~] your communication is synchronous
- with [netsend]/[netreceive] your communication is asynchronous

So (if i am right), if something is heavy to compute (more than 100% of
your CPU) in your subprocess with [pd~], your parent have to wait the
end of this computation. This is not the case with [netsend]/[netreceive].
++

Jack


> 
> On Tue, Feb 23, 2016 at 5:45 PM, David Medine  > wrote:
> 
> I think we all need to learn more about multi-threading if we want
> to run real-time, modular, digital signal processing algorithms on
> multi-core machines. I, for one, can not think of any general,
> robust way to do this. In that sense, Pd's adherence to single
> threading is actually a very elegant solution to the problem.
> 
> 
> On 2/23/2016 12:25 PM, martin brinkmann wrote:
> 
> On 22/02/16 02:49, Matti Viljamaa wrote:
> 
> How do you think Pure Data is limited?
> 
> for me the only real and important (i can think of at the
> moment) limitation is the block-based audio processing.
> to me this seems quite unnatural and inconvenient when dealing with
> digital audio. it kept me for a couple of years from using pd,
> though it
> is only a 'showstopper' in rather few cases, i found out.
> feedback in large/complex patches for example, since it
> is not very practical (or possible at all) to re-block
> everything to 1...
> 
> what i tried but couldn't (yet): build a decent piano-roll
> editor (vanilla).
> 
> and i believe too, pd has to 'learn' better multithreading to run
> adequately on our future machines with hundreds or even thousands of
> arm-cores...
> 
> ___
> Pd-list@lists.iem.at  mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
> 
> 
> 
> ___
> Pd-list@lists.iem.at  mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
> 
> 
> 
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list
> 


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

Re: [PD] How's Pd limited?

[Eugene Lazarchik]

Thanks for replying, Jonathan.

If Pd-l2ork starts to supports Mac I'll seriously consider switching to it.
Sounds like many of the issues and inconveniences are fixed there. Let me
reply to your questions.

> * Standard GUI objects are ugly and have limited functionality.
>
> Yes.  Just curious-- what's the most critical functionality you feel is
> missing?
>

I don't recall all of my frustrations with the GUI objects, I just remember
there were many. But let me try.
 * A button object. You know, a rectangle with a piece of text that can be
clicked to generate a bang. Usually people put a bang next to a comment,
but it takes more space. I've also seen people implementing load and save
buttons by putting "L" and "S" inside bangs. It looks really ugly and is
hard to read, especially when the bang is small. When I first saw the
browser 
abstraction from the mmb library I was very curious how it works. Turns
out, it uses sliders! They send messages when are clicked and slider
position indicator can be hidden by choosing colors in the properties menu.
I think this is a great illustration to how often PD makes us create
hacks/workarounds instead of having a nice straightforward solution.
 * Ability to remove "dented" corners (symbolbox and numberbox) and the
triangle from number2, as well as hide the border completely. They can be
helpful when doing quick prototyping but when I'm building a nice GUI, I
often don't want to see them.
 * A text box that visually indicates that it has focus and stuff is
getting entered. Even better: show a cursor, allow to move it around and
select and copy/paste text.
 * Some kind of API to determine mouse coordinates _relative to the GOP_.
Currently there seems to be no way of, say, building a menu abstraction
that will highlight menu items when mouse cursor hovers over them (it
should work regardless of how many subpatches deep it's situated and which
of the parent subpatches is currently open).
 * Drop-down list and selectbox, working out of the box, no external
libraries.
 * Ability to edit subpatch/abstraction arguments from the properties menu
when subpatch/abstraction is in GOP mode with hidden arguments. Currently
one has to disable GOP, edit the arguments, reenable GOP again.
 * Ability to hide inlets/outlets when using GOP. The little boxes are
often distracting and they take additional space. Currently a similar
effect can be achieved by placing a canvas of the same size as the GOP area
that covers it.


> > * There's no good support for the concept of functions/procedures. Let's
> say we need to take some input, do some transformations and produce output,
> and we need to do that in multiple places in our patch. We can copy the
> objects but that will make the patch use more memory and there will be no
> code reuse. Another way is to make that an abstraction, but it's silly to
> make abstractions for every little thing that we need in 2 places. Also,
> instantiating 2 abstractions still uses more memory. We can try reusing the
> same code but we'll have to make multiple output connections so we'll need
> proper routing in order to figure out where to send the result. I made an
> abstraction to simplify that but this should be a standard feature of PD.
>
> What are the practical limitations of the higher memory use in these
> cases?  You're still going to have the same message passing overhead.
>

I don't know too much about how PD works internally but I imagine it
probably maps all objects into some data structure in memory and then
passes messages around by going from one object to another. The more
objects is there in the patch and all subpatches, the more memory it'll
take. It's probably a very small amount of memory per object, but
theoretically it can add up (if certain abstractions are used multiple
times in other abstractions, which are used multiple times in other
abstractions, etc.), especially on mobile platforms. Maybe the additional
memory usage is always very tiny, I don't know. But it feels weird to be
wasteful.

Anyway, there's other use cases for this concept. Imagine object [pd A]
that is a storage of some type. When banged on the inlet it sends the
storage contents to the outlet. Objects [B], [C] and [D] need to be able to
query the contents of object [A]'s storage. We can connect their outlets to
[A] so that they can send a bang to it but how do we route the output? We
don't want [C] and [D] to receive the output when [B] sends a bang to [A].
We can use spigots or store the output in intermediate objects ([float],
[symbol], [list]) but it all complicates the patch and makes it less
readable. I created a [func] abstraction that can be used like this:

[inlet from B]
|
[func]x[pd A]<= A may be connected to other objects but we'll
ignore all output from it unless a message from B initiated it
|
[outlet to B]

It ignores all input from the right inlet unless a 

Re: [PD] How's Pd limited?

[Alexandros Drymonitis]

On Wed, Feb 24, 2016 at 3:48 AM, Chris McCormick  wrote:

> On 22/02/16 09:49, Matti Viljamaa wrote:
>
>> How do you think Pure Data is limited?
>>
>
> expr~ tanh($v1)
>
If you copy the [tanh] abstraction from purepd and make it a signal one,
doesn't that work? Then it's vanilla.
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] How's Pd limited?

[Chris McCormick]

On 22/02/16 09:49, Matti Viljamaa wrote:

How do you think Pure Data is limited?


expr~ tanh($v1)

I would apologise for being a smart-ass but I don't feel sorry.

Cheers,

Chris.

--
http://mccormick.cx/

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

Re: [PD] How's Pd limited?

[Matt Barber]

Can anyone explain more why [pd~] doesn't fulfill the desire for parallel
processing, and maybe provide an example of something outside of Pd that
does? I don't feel like I have a great handle on the design. As Jonathan
said, it seems like Pd's determinism constraint is a big hurdle to clear,
though it's already relaxed a bit with netsend/receive. What are the main
differences between running an instance of Pd as a [pd~] slave to another
instance, and running two instances that communicate via netsend/receive
and jack?

On Tue, Feb 23, 2016 at 5:45 PM, David Medine  wrote:

> I think we all need to learn more about multi-threading if we want to run
> real-time, modular, digital signal processing algorithms on multi-core
> machines. I, for one, can not think of any general, robust way to do this.
> In that sense, Pd's adherence to single threading is actually a very
> elegant solution to the problem.
>
>
> On 2/23/2016 12:25 PM, martin brinkmann wrote:
>
>> On 22/02/16 02:49, Matti Viljamaa wrote:
>>
>> How do you think Pure Data is limited?
>>>
>> for me the only real and important (i can think of at the
>> moment) limitation is the block-based audio processing.
>> to me this seems quite unnatural and inconvenient when dealing with
>> digital audio. it kept me for a couple of years from using pd, though it
>> is only a 'showstopper' in rather few cases, i found out.
>> feedback in large/complex patches for example, since it
>> is not very practical (or possible at all) to re-block
>> everything to 1...
>>
>> what i tried but couldn't (yet): build a decent piano-roll
>> editor (vanilla).
>>
>> and i believe too, pd has to 'learn' better multithreading to run
>> adequately on our future machines with hundreds or even thousands of
>> arm-cores...
>>
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] How's Pd limited?

[David Medine]

I think we all need to learn more about multi-threading if we want to 
run real-time, modular, digital signal processing algorithms on 
multi-core machines. I, for one, can not think of any general, robust 
way to do this. In that sense, Pd's adherence to single threading is 
actually a very elegant solution to the problem.


On 2/23/2016 12:25 PM, martin brinkmann wrote:

On 22/02/16 02:49, Matti Viljamaa wrote:


How do you think Pure Data is limited?

for me the only real and important (i can think of at the
moment) limitation is the block-based audio processing.
to me this seems quite unnatural and inconvenient when dealing with
digital audio. it kept me for a couple of years from using pd, though it
is only a 'showstopper' in rather few cases, i found out.
feedback in large/complex patches for example, since it
is not very practical (or possible at all) to re-block
everything to 1...

what i tried but couldn't (yet): build a decent piano-roll
editor (vanilla).

and i believe too, pd has to 'learn' better multithreading to run
adequately on our future machines with hundreds or even thousands of
arm-cores...

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



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

Re: [PD] How's Pd limited?

[Esteban Viveros]

O.oSo easy!!

Em ter, 23 de fev de 2016 às 07:44, Dan Wilcox 
escreveu:

> Em ter, 23 de fev de 2016 às 00:56, Matt Barber 
> escreveu:
>
>> Newest vanilla has basic object resize, which actually helps a lot with
>> some of the issues brought up here. It's also very helpful that comments
>> can be resized, so you can set the wrap point.
>>
>> Cool.. I'm using pd 0.46-7, what's that object? :)
>
>
> Hover your mouse over the right side of an object box and drag…
>
> 
> Dan Wilcox
> @danomatika 
> danomatika.com
> robotcowboy.com
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] How's Pd limited?

[martin brinkmann]

On 22/02/16 02:49, Matti Viljamaa wrote:

> How do you think Pure Data is limited?

for me the only real and important (i can think of at the
moment) limitation is the block-based audio processing.
to me this seems quite unnatural and inconvenient when dealing with
digital audio. it kept me for a couple of years from using pd, though it
is only a 'showstopper' in rather few cases, i found out.
feedback in large/complex patches for example, since it
is not very practical (or possible at all) to re-block
everything to 1...

what i tried but couldn't (yet): build a decent piano-roll
editor (vanilla).

and i believe too, pd has to 'learn' better multithreading to run
adequately on our future machines with hundreds or even thousands of
arm-cores...

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

Re: [PD] How's Pd limited?

[Jonathan Wilkes via Pd-list]

> Align: https://youtu.be/lCIeIelbw74
Looks like there's a whole collection of tools to do that, including a 
transient bbox with drag hooks.

> Route Patch Cords: https://youtu.be/2u_UJQ8OfvUI'm pretty sure Pd-l2ork can 
> do the first part of that video.  But it can also do a many-to-one 
> auto-connection which is 
more ergonomic.
 

On Tuesday, February 23, 2016 1:13 AM, Esteban Viveros 
 wrote:
 

 Like that:
Align: https://youtu.be/lCIeIelbw74Route Patch Cords: 
https://youtu.be/2u_UJQ8OfvU


Em ter, 23 de fev de 2016 às 02:09, Jonathan Wilkes  
escreveu:

> Here's a radical idea that I've sometimes pondered: what if we could create 
>left-inlets and right-outlets as well as the standard top- and bottom- ones? 
If the object has more than one inlet or outlet you wouldn't be able to fit 
them on the side of the object box.
Also, you run into a common UI problem: if you rotate a thing ninety degrees, 
do you rotate clockwise or counterclockwise?  If I push "up" on a DirectTv 
remote the channel guide on the screen scrolls down (and the numbers 
decrease!), but if I slide my fingers up a MacBook touchpad the browser window 
scrolls upward.  Similarly, vertically-placed outlets could fire top-down or 
bottom-up.  Maybe one is somehow more natural than the other, but off the top 
of my head I can't think which.  So I think you'd get more conceptual 
complexity in return for visual left-to-right flow.
[expr] helps to fill the role you describe.  Unfortunately the 
Max-compatibility creates more complexity, making Pd's mantra of "everything is 
a float" turn into "everything is a float unless it follows the syntax of that 
other software which you may or may not have learned..."
-Jonathan


On Monday, February 22, 2016 11:40 PM, Jonathan Wilkes  
wrote:
 

 > Max have features like auto-align horizontally/vertically
Pd-l2ork has this, too-- "Tidy Up" in the Edit menu.  It's a little strange-- 
if you click it once it will sweep the selected objects into a "pile", and if 
you click again it will fan them out like a deck of cards.  But it can work 
well for some situations.
> and align and route patch cords which is very useful to organize patch cords 
> and make the thinks more readable. I like them a lot.
That's a side-effect of "Tidy Up" in a lot of cases, at least for the leftmost 
inlets and outlets.
-Jonathan
 

On Monday, February 22, 2016 10:49 PM, Esteban Viveros 
 wrote:
 

 A feature I miss in vanilla and extended (pdl2ork solve that) is resize 
objects via one point click and drag. If it is hard to implement, a "apply" 
button on properties can help to design UI's in Vanilla.
Max have features like auto-align horizontally/vertically and align and route 
patch cords which is very useful to organize patch cords and make the thinks 
more readable. I like them a lot.
Em seg, 22 de fev de 2016 às 23:49, Johnny Mauser via Pd-list 
 escreveu:

That's something i completly experiece diffrently!! Pd fucks up in practise and 
development quiet often (maybe i make it fuck up) but once it runs, it runs 
stable every time!!Love to pd, Johnny Am 23.02.2016 02:20 schrieb "Morten 
Minothi Kristiansen" :

Not tried different builds, please giide me.23. feb. 2016 02.20 skrev "Morten 
Minothi Kristiansen" :

Its been like this with Mavericks, Yosemite and El capitalist. Pd extended 
0.43. I did a clean install a week ago and it worked fine for a week until I 
installed live 9. It still worked until it suddenly hit some kond of wall 
again.Mort23. feb. 2016 02.15 skrev "AP Vague" :

Woah, that's definitely a problem I haven't heard of... I'm guessing you've 
already tried using different builds. What OS are you on?
On Mon, Feb 22, 2016 at 7:07 PM, Morten Minothi Kristiansen  
wrote:

On my last two comouters PD wont open unless I start it with a standalone patch 
I made long ago. It works for a little while, then crashes completely and for 
ever more...unless I use the stand alone. Recently...5 min before a gig the 
standalone wouldnt even start. The gig was fine as Im nott 100% relying on pd, 
but I have lost faith in PD EXTENDED and wish someone could have helped me 
earlier with this. I have posted and searched for answears, but didnt get 
nothing back. Aaaarrrhhh!!! I would mayyybe make a few more attempts if 
only someone serious would help me out with this and fix the problem, but thats 
yet to be the case. Ok... sorry about the rant. Had to get it out and now Im 
moving on with Max. Yebo
Morten 22. feb. 2016 02.52 skrev "Matti Viljamaa" :

Perhaps a bit of broad question, but I find it interesting in order to 
speculate about future additions.

How do you think Pure Data is limited?
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management 

Re: [PD] How's Pd limited?

[Matt Barber]

If you're using the newest vanilla, the [array] object lets you get a range
of a given size from an index onset as a list, and to put the list at an
onset of another array. It's faster than I thought it would be. So, you
could just load your files sequentially into one table and copy them from
there, or you could load them all into their own table and copy each one
separately. I don't know which would be faster. As long as you're not
resizing the table each time you load, I'd probably go with the first
option. Just remember that [soundfiler] runs synchronously, so you don't
want to do any of this in the middle of the operation.

On Tue, Feb 23, 2016 at 2:49 PM, Samuel Burt  wrote:

> I guess I've never seen a way to load multiple samples into a single
> array. That might solve another problem I'm currently sorting out. How do
> you do that?
>
> Sam
>
>
> On Tue, Feb 23, 2016, 1:56 PM Matt Barber  wrote:
>
>> This is doable, actually, but not easy. [delay] and [vline~] both have
>> subsample accuracy. It would be substantially easier if you could
>> preprocess and deliver the sequence as one big message dump to [vline~]. If
>> you loaded all of the files into one array (up to about 6:20 of audio at
>> 44100) and kept tabs on where each one started and how long it was in
>> samples and milliseconds, you could then feed [vline~] into [tabread~] to
>> play the relevant chunk of the array. If you needed to be able to transpose
>> them, that's a little harder because depending on how long the table was,
>> you'd need to work in the message onset to [tabread4~]'s right inlet or
>> face index degradation.
>>
>> On Tue, Feb 23, 2016 at 1:40 PM, Samuel Burt <
>> composer.samuel.b...@gmail.com> wrote:
>>
>>> David,
>>>
>>> One thing I attempted and couldn't find a solution for was the
>>> following, mostly owing to the limitation of interfacing with a 64 sample
>>> block size.
>>>
>>> I wanted to have a directory of hundreds of audio recordings. Each one
>>> would be a single wavelength from an interesting sound, like a bass
>>> clarinet, marimba, harpsichord, tambourine, etc. Each would begin and end
>>> at a zero crossing so you could chain them together to make complex
>>> timbres. They could be chained in sequence, randomized, or loaded in
>>> meta-data-matched chunks. I ran into a problem figuring out how to trigger
>>> the next sound based on the ending of the last sound in a sample accurate
>>> way. Sound file loading or even buffer playback triggering waits until the
>>> start of the next block size before it updates. If you have a waveform that
>>> lasts 205 samples (64+64+64+13), you have a gap of 51 silent samples before
>>> the next waveform would start. Not only do you not get the continuous sound
>>> you want, this winds up creating a periodic pattern with a frequency of 689
>>> Hz (44100/64).
>>>
>>> David, I like your idea "what (if anything) someone tried to do in Pd,
>>> but couldn't given its limitations". I think this could be a wonderful
>>> challenge if we could have a monthly thread like this where the best minds
>>> among us come up with solutions to some of the hardest conceptual
>>> challenges in Pd.
>>>
>>> I'm still struggling with loading dozens of files, audio dropouts, and
>>> other similar problems. Someone else expressed frustration about Pd's
>>> single-threaded status. I too have feared upgrading my computer based on
>>> the limitations of current multicore processors (although realistically I
>>> think we can all look at the "turbo-boost" level or whatever Intel calls it
>>> to determine where our processor might run with a demanding patch. I
>>> understand the fact that you can't run your audio process on multiple
>>> cores, because it is a linear process. It would be great if the GUI could
>>> run on a second core, a process that loads audio into memory could run on
>>> third core, while GEM could automatically run on a fourth core. I don't
>>> have any concept of how feasible that would be, though. Does the GUI in
>>> pd-l2orc run on a separate core?
>>>
>>> Sam
>>>
>>>
>>>
>>>
>>>
>>>
 Message: 4
 Date: Tue, 23 Feb 2016 09:01:06 -0800
 From: david medine 

 One thing I'd be interested in knowing about is what (if anything)
 someone tried to do in Pd, but couldn't given its limitations (apart
 from look/feel/convenience issues).


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

Re: [PD] How's Pd limited?

[Samuel Burt]

I guess I've never seen a way to load multiple samples into a single array.
That might solve another problem I'm currently sorting out. How do you do
that?

Sam

On Tue, Feb 23, 2016, 1:56 PM Matt Barber  wrote:

> This is doable, actually, but not easy. [delay] and [vline~] both have
> subsample accuracy. It would be substantially easier if you could
> preprocess and deliver the sequence as one big message dump to [vline~]. If
> you loaded all of the files into one array (up to about 6:20 of audio at
> 44100) and kept tabs on where each one started and how long it was in
> samples and milliseconds, you could then feed [vline~] into [tabread~] to
> play the relevant chunk of the array. If you needed to be able to transpose
> them, that's a little harder because depending on how long the table was,
> you'd need to work in the message onset to [tabread4~]'s right inlet or
> face index degradation.
>
> On Tue, Feb 23, 2016 at 1:40 PM, Samuel Burt <
> composer.samuel.b...@gmail.com> wrote:
>
>> David,
>>
>> One thing I attempted and couldn't find a solution for was the following,
>> mostly owing to the limitation of interfacing with a 64 sample block size.
>>
>> I wanted to have a directory of hundreds of audio recordings. Each one
>> would be a single wavelength from an interesting sound, like a bass
>> clarinet, marimba, harpsichord, tambourine, etc. Each would begin and end
>> at a zero crossing so you could chain them together to make complex
>> timbres. They could be chained in sequence, randomized, or loaded in
>> meta-data-matched chunks. I ran into a problem figuring out how to trigger
>> the next sound based on the ending of the last sound in a sample accurate
>> way. Sound file loading or even buffer playback triggering waits until the
>> start of the next block size before it updates. If you have a waveform that
>> lasts 205 samples (64+64+64+13), you have a gap of 51 silent samples before
>> the next waveform would start. Not only do you not get the continuous sound
>> you want, this winds up creating a periodic pattern with a frequency of 689
>> Hz (44100/64).
>>
>> David, I like your idea "what (if anything) someone tried to do in Pd,
>> but couldn't given its limitations". I think this could be a wonderful
>> challenge if we could have a monthly thread like this where the best minds
>> among us come up with solutions to some of the hardest conceptual
>> challenges in Pd.
>>
>> I'm still struggling with loading dozens of files, audio dropouts, and
>> other similar problems. Someone else expressed frustration about Pd's
>> single-threaded status. I too have feared upgrading my computer based on
>> the limitations of current multicore processors (although realistically I
>> think we can all look at the "turbo-boost" level or whatever Intel calls it
>> to determine where our processor might run with a demanding patch. I
>> understand the fact that you can't run your audio process on multiple
>> cores, because it is a linear process. It would be great if the GUI could
>> run on a second core, a process that loads audio into memory could run on
>> third core, while GEM could automatically run on a fourth core. I don't
>> have any concept of how feasible that would be, though. Does the GUI in
>> pd-l2orc run on a separate core?
>>
>> Sam
>>
>>
>>
>>
>>
>>
>>> Message: 4
>>> Date: Tue, 23 Feb 2016 09:01:06 -0800
>>> From: david medine 
>>>
>>> One thing I'd be interested in knowing about is what (if anything)
>>> someone tried to do in Pd, but couldn't given its limitations (apart
>>> from look/feel/convenience issues).
>>>
>>>
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] How's Pd limited?

[Dan Wilcox]

> On Feb 23, 2016, at 11:19 AM, pd-list-requ...@lists.iem.at wrote:
> 
> It's an incremental approach, so it still suffers from socket chatter 
> problems that tcl/tk Pd has.  But now that tcl/tk is removed from the C code, 
> logic is slowly making its way over to the GUI side.

I’m hoping to build upon this work by looking into integrating this approach 
into libpd. Keep it up :)


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 


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

Re: [PD] How's Pd limited?

[Matt Barber]

This is doable, actually, but not easy. [delay] and [vline~] both have
subsample accuracy. It would be substantially easier if you could
preprocess and deliver the sequence as one big message dump to [vline~]. If
you loaded all of the files into one array (up to about 6:20 of audio at
44100) and kept tabs on where each one started and how long it was in
samples and milliseconds, you could then feed [vline~] into [tabread~] to
play the relevant chunk of the array. If you needed to be able to transpose
them, that's a little harder because depending on how long the table was,
you'd need to work in the message onset to [tabread4~]'s right inlet or
face index degradation.

On Tue, Feb 23, 2016 at 1:40 PM, Samuel Burt  wrote:

> David,
>
> One thing I attempted and couldn't find a solution for was the following,
> mostly owing to the limitation of interfacing with a 64 sample block size.
>
> I wanted to have a directory of hundreds of audio recordings. Each one
> would be a single wavelength from an interesting sound, like a bass
> clarinet, marimba, harpsichord, tambourine, etc. Each would begin and end
> at a zero crossing so you could chain them together to make complex
> timbres. They could be chained in sequence, randomized, or loaded in
> meta-data-matched chunks. I ran into a problem figuring out how to trigger
> the next sound based on the ending of the last sound in a sample accurate
> way. Sound file loading or even buffer playback triggering waits until the
> start of the next block size before it updates. If you have a waveform that
> lasts 205 samples (64+64+64+13), you have a gap of 51 silent samples before
> the next waveform would start. Not only do you not get the continuous sound
> you want, this winds up creating a periodic pattern with a frequency of 689
> Hz (44100/64).
>
> David, I like your idea "what (if anything) someone tried to do in Pd, but
> couldn't given its limitations". I think this could be a wonderful
> challenge if we could have a monthly thread like this where the best minds
> among us come up with solutions to some of the hardest conceptual
> challenges in Pd.
>
> I'm still struggling with loading dozens of files, audio dropouts, and
> other similar problems. Someone else expressed frustration about Pd's
> single-threaded status. I too have feared upgrading my computer based on
> the limitations of current multicore processors (although realistically I
> think we can all look at the "turbo-boost" level or whatever Intel calls it
> to determine where our processor might run with a demanding patch. I
> understand the fact that you can't run your audio process on multiple
> cores, because it is a linear process. It would be great if the GUI could
> run on a second core, a process that loads audio into memory could run on
> third core, while GEM could automatically run on a fourth core. I don't
> have any concept of how feasible that would be, though. Does the GUI in
> pd-l2orc run on a separate core?
>
> Sam
>
>
>
>
>
>
>> Message: 4
>> Date: Tue, 23 Feb 2016 09:01:06 -0800
>> From: david medine 
>>
>> One thing I'd be interested in knowing about is what (if anything)
>> someone tried to do in Pd, but couldn't given its limitations (apart
>> from look/feel/convenience issues).
>>
>>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] How's Pd limited?

[Jonathan Wilkes via Pd-list]

Does the GUI in pd-l2orc run on a separate core?
For all versions of Pd, the GUI runs as a separate process.  It communicates 
with the Pd process over a TCP socket.
-Jonathan
 

On Tuesday, February 23, 2016 1:51 PM, Samuel Burt 
 wrote:
 

 David,
One thing I attempted and couldn't find a solution for was the following, 
mostly owing to the limitation of interfacing with a 64 sample block size.
I wanted to have a directory of hundreds of audio recordings. Each one would be 
a single wavelength from an interesting sound, like a bass clarinet, marimba, 
harpsichord, tambourine, etc. Each would begin and end at a zero crossing so 
you could chain them together to make complex timbres. They could be chained in 
sequence, randomized, or loaded in meta-data-matched chunks. I ran into a 
problem figuring out how to trigger the next sound based on the ending of the 
last sound in a sample accurate way. Sound file loading or even buffer playback 
triggering waits until the start of the next block size before it updates. If 
you have a waveform that lasts 205 samples (64+64+64+13), you have a gap of 51 
silent samples before the next waveform would start. Not only do you not get 
the continuous sound you want, this winds up creating a periodic pattern with a 
frequency of 689 Hz (44100/64).
David, I like your idea "what (if anything) someone tried to do in Pd, but 
couldn't given its limitations". I think this could be a wonderful challenge if 
we could have a monthly thread like this where the best minds among us come up 
with solutions to some of the hardest conceptual challenges in Pd.
I'm still struggling with loading dozens of files, audio dropouts, and other 
similar problems. Someone else expressed frustration about Pd's single-threaded 
status. I too have feared upgrading my computer based on the limitations of 
current multicore processors (although realistically I think we can all look at 
the "turbo-boost" level or whatever Intel calls it to determine where our 
processor might run with a demanding patch. I understand the fact that you 
can't run your audio process on multiple cores, because it is a linear process. 
It would be great if the GUI could run on a second core, a process that loads 
audio into memory could run on third core, while GEM could automatically run on 
a fourth core. I don't have any concept of how feasible that would be, though. 
Does the GUI in pd-l2orc run on a separate core?
Sam






Message: 4
Date: Tue, 23 Feb 2016 09:01:06 -0800
From: david medine 

One thing I'd be interested in knowing about is what (if anything)
someone tried to do in Pd, but couldn't given its limitations (apart
from look/feel/convenience issues).



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


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

Re: [PD] How's Pd limited?

[Samuel Burt]

David,

One thing I attempted and couldn't find a solution for was the following,
mostly owing to the limitation of interfacing with a 64 sample block size.

I wanted to have a directory of hundreds of audio recordings. Each one
would be a single wavelength from an interesting sound, like a bass
clarinet, marimba, harpsichord, tambourine, etc. Each would begin and end
at a zero crossing so you could chain them together to make complex
timbres. They could be chained in sequence, randomized, or loaded in
meta-data-matched chunks. I ran into a problem figuring out how to trigger
the next sound based on the ending of the last sound in a sample accurate
way. Sound file loading or even buffer playback triggering waits until the
start of the next block size before it updates. If you have a waveform that
lasts 205 samples (64+64+64+13), you have a gap of 51 silent samples before
the next waveform would start. Not only do you not get the continuous sound
you want, this winds up creating a periodic pattern with a frequency of 689
Hz (44100/64).

David, I like your idea "what (if anything) someone tried to do in Pd, but
couldn't given its limitations". I think this could be a wonderful
challenge if we could have a monthly thread like this where the best minds
among us come up with solutions to some of the hardest conceptual
challenges in Pd.

I'm still struggling with loading dozens of files, audio dropouts, and
other similar problems. Someone else expressed frustration about Pd's
single-threaded status. I too have feared upgrading my computer based on
the limitations of current multicore processors (although realistically I
think we can all look at the "turbo-boost" level or whatever Intel calls it
to determine where our processor might run with a demanding patch. I
understand the fact that you can't run your audio process on multiple
cores, because it is a linear process. It would be great if the GUI could
run on a second core, a process that loads audio into memory could run on
third core, while GEM could automatically run on a fourth core. I don't
have any concept of how feasible that would be, though. Does the GUI in
pd-l2orc run on a separate core?

Sam






> Message: 4
> Date: Tue, 23 Feb 2016 09:01:06 -0800
> From: david medine 
>
> One thing I'd be interested in knowing about is what (if anything)
> someone tried to do in Pd, but couldn't given its limitations (apart
> from look/feel/convenience issues).
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] How's Pd limited?

[Jonathan Wilkes via Pd-list]

But I guess pd-l2ork addresses some of these issues? I know Jonathan has done a 
lot of work on a node webkit gui for pd: https://github.com/jonwwilkes/pd-nw
That's a mirror that I stopped updating awhile back.
The repo is here:https://puredata.osuosl.org/
It's an incremental approach, so it still suffers from socket chatter problems 
that tcl/tk Pd has.  But now that tcl/tk is removed from the C code, 
logic is slowly making its way over to the GUI side.
 
For example-- there is no longer any socket chatter when you're typing inside 
an object box.  That all gets handled by the GUI, which means that 
all the editing bindings you're used to in a browser work exactly the same way. 
 It also means the C code that used to handle these details can 
be removed.

Here's a one-eyed pirate cat walking around in a 
patch:pdblog.nfshost.com/catchar.webm
As you can see it looks just like the current incarnation of Pd-l2ork.  There 
are also skins for Pd Vanilla, Extended, C64, and Strongbad.
-Jonathan
 

On Tuesday, February 23, 2016 12:52 PM, Jonathan Wilkes 
 wrote:
 

 > if you like your fancy gui's, use them!
Pd's GUI is plain and limited, yes.  But what it lacks in beauty it makes up 
for in tcp socket chatter.
-Jonathan 

On Tuesday, February 23, 2016 12:02 PM, david medine  
wrote:
 

  One thing I'd be interested in knowing about is what (if anything) someone 
tried to do in Pd, but couldn't given its limitations (apart from 
look/feel/convenience  issues). 
 
 On 2/23/16 8:54 AM, Matt Barber wrote:
  
 
 This thread has inspired me to work on a fork called Pd-limited.  
 On Tue, Feb 23, 2016 at 11:27 AM, jamal crawford  wrote:
 
  hi list
    >Max have features like auto-align horizontally/vertically and align and 
route patch cords which is very useful to >organize patch cords and make the  
thinks more readable. I like them a lot.
    this is so old. this comparing  so old.
  if you like your fancy gui's, use them! have you heard of OSC? just dump 
whatever you want thru it and run a headless instance of pd, where you recieve 
it. nobody will even notice. are you a nerd or just pretending :P
  sorry no offence .)
  peace
~/.jc
      
 ___
 Pd-list@lists.iem.at mailing list
 UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list
 
 
  
  
  
 ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list
 
 
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list


   

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

Re: [PD] How's Pd limited?

[Jonathan Wilkes via Pd-list]

> if you like your fancy gui's, use them!
Pd's GUI is plain and limited, yes.  But what it lacks in beauty it makes up 
for in tcp socket chatter.
-Jonathan 

On Tuesday, February 23, 2016 12:02 PM, david medine  
wrote:
 

  One thing I'd be interested in knowing about is what (if anything) someone 
tried to do in Pd, but couldn't given its limitations (apart from 
look/feel/convenience  issues). 
 
 On 2/23/16 8:54 AM, Matt Barber wrote:
  
 
 This thread has inspired me to work on a fork called Pd-limited.  
 On Tue, Feb 23, 2016 at 11:27 AM, jamal crawford  wrote:
 
  hi list
    >Max have features like auto-align horizontally/vertically and align and 
route patch cords which is very useful to >organize patch cords and make the  
thinks more readable. I like them a lot.
    this is so old. this comparing  so old.
  if you like your fancy gui's, use them! have you heard of OSC? just dump 
whatever you want thru it and run a headless instance of pd, where you recieve 
it. nobody will even notice. are you a nerd or just pretending :P
  sorry no offence .)
  peace
~/.jc
      
 ___
 Pd-list@lists.iem.at mailing list
 UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list
 
 
  
  
  
 ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list
 
 
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list


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

Re: [PD] How's Pd limited?

[Brian Fay]

On Tue, Feb 23, 2016 at 11:27 AM, jamal crawford  wrote:

if you like your fancy gui's, use them! have you heard of OSC? just dump
> whatever you want thru it and run a headless instance of pd, where you
> recieve it. nobody will even notice. are you a nerd or just pretending :P
>
>
If you have a static patch where you don't need to dynamically add or
remove objects, building an external gui is fine and dandy. But Liam is
basically saying he isn't satisfied with the tcl/tk patching interface and
would like an alternative. As far as I am aware libpd doesn't have hooks
for adding, removing, and connecting objects. You can't build an
alternative gui. In my mind this is the most severe limitation of pd.

But I guess pd-l2ork addresses some of these issues? I know Jonathan has
done a lot of work on a node webkit gui for pd:
https://github.com/jonwwilkes/pd-nw
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] How's Pd limited?

[Matt Barber]

This thread has inspired me to work on a fork called Pd-limited.

On Tue, Feb 23, 2016 at 11:27 AM, jamal crawford  wrote:

> hi list
>
>
> >Max have features like auto-align horizontally/vertically and align and
> route patch cords which is very useful to >organize patch cords and make
> the  thinks more readable. I like them a lot.
>
> this is so old. this comparing  so old.
> if you like your fancy gui's, use them! have you heard of OSC? just dump
> whatever you want thru it and run a headless instance of pd, where you
> recieve it. nobody will even notice. are you a nerd or just pretending :P
> sorry no offence .)
> peace
> ~/.jc
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] How's Pd limited?

[jamal crawford]

hi list

>Max have features like auto-align horizontally/vertically and align and
>route patch cords which is very useful to >organize patch cords and
>make the  thinks more readable. I like them a lot.

this is so old. this comparing  so old. if you like your fancy
gui's, use them! have you heard of OSC? just dump whatever you want thru
it and run a headless instance of pd, where you recieve it. nobody will
even notice. are you a nerd or just pretending :P sorry no offence .)
peace ~/.jc
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] How's Pd limited?

[Alexandre Torres Porres]

2016-02-23 12:44 GMT-03:00 Roman Haefeli :

> In my experience, more often I resize the box accidentally than
> willingly. I'd welcome a way to disable this feature.


How about "shift + click and drag"?
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] How's Pd limited?

[Roman Haefeli]

On Tue, 2016-02-23 at 09:30 -0500, Ivica Ico Bukvic wrote:
> I forget, does the mouse cursor change when you hover? Last time I
> checked in vanilla it didn't but that was a while ago. If not, it may
> help make it easier to expose the said feature and aim for the sweet
> spot.

It becomes a double-arrow (left-right). However, when releasing the
mouse key after changing the box width, the box content is marked and
you can't change width anymore. You have to first click somewhere into
to canvas to unmark the box in order to be able to resize the box again.

In my experience, more often I resize the box accidentally than
willingly. I'd welcome a way to disable this feature.

Roman


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] How's Pd limited?

[Jonathan Wilkes via Pd-list]

> I'd love if Pd would provide some true multi-threading (not like [pd~] which 
> is tightly coupled to its parent).
How would the patch/audio remain determinstic if the units in the dsp graph 
aren't tightly coupled?

-Jonathan


On Tuesday, February 23, 2016 9:34 AM, Ivica Ico Bukvic  wrote:
 

  I forget, does the mouse cursor change when you hover? Last time I checked in 
vanilla it didn't but that was a while ago. If not, it may help make it easier 
to expose the said feature and aim for the sweet spot.
 
 On 2/23/2016 5:44 AM, Dan Wilcox wrote:
  
 
 
   Em ter, 23 de fev de 2016 às 00:56, Matt Barber  
escreveu:
  
  Newest vanilla has basic object resize, which actually helps a lot with some 
of the issues brought up here. It's also very  helpful that comments can be 
resized, so you can set the wrap point.  
  
 Cool.. I'm using pd 0.46-7, what's that object? :)   
 
  Hover your mouse over the right side of an object box and drag… 
  
 Dan Wilcox
 @danomatika
 danomatika.com
 robotcowboy.com   
  
  
 ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list
 
 
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list


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

Re: [PD] How's Pd limited?

[Ivica Ico Bukvic]

I forget, does the mouse cursor change when you hover? Last time I 
checked in vanilla it didn't but that was a while ago. If not, it may 
help make it easier to expose the said feature and aim for the sweet spot.


On 2/23/2016 5:44 AM, Dan Wilcox wrote:
Em ter, 23 de fev de 2016 às 00:56, Matt Barber > escreveu:


Newest vanilla has basic object resize, which actually helps a
lot with some of the issues brought up here. It's also very
helpful that comments can be resized, so you can set the wrap point.

Cool.. I'm using pd 0.46-7, what's that object? :)


Hover your mouse over the right side of an object box and drag…


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 



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


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

Re: [PD] How's Pd limited?

[Ivica Ico Bukvic]

On 2/22/2016 11:40 PM, Jonathan Wilkes via Pd-list wrote:

> Max have features like auto-align horizontally/vertically

Pd-l2ork has this, too-- "Tidy Up" in the Edit menu.  It's a little 
strange-- if you click it once it will sweep the selected objects into a
"pile", and if you click again it will fan them out like a deck of 
cards.  But it can work well for some situations.


This is because in pd-l2ork first press on tidy up aligns objects to the 
closest axis. This can sometimes make objects overlap, even though they 
are aligned across a desired axis (e.g. if you duplicate an object a 
couple times and then try to align it with duplicated objects). That is 
why there is the second press which spaces out objects according to the 
shortest space between them unless the shortest space is an actual 
overlap in which case it respaces it by a default spacing value that is 
applied to the right side of the object to the left. Now, if you can 
understand what I wrote in one read, go get yourself (if age < 21 && 
location == USA; then popsicle; else beer;)



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

Re: [PD] How's Pd limited?

[patrice colet]

Hello,
 keeping track of send/receive is not very difficult, just put a few s/r names 
in your patches and use a [route] object to your different methods
then you can get easier in console what happens in FUDI.


Le 22/02/2016 22:57, Peter Nyboer a écrit :

I also dislike Send and Receive, but end up using them in pd. I don’t like that 
they are hard to keep track of (I see the receive, where’s the send?). I guess 
$0 does clear up the global issues, but it feels hacky. I managed to get rid of 
them in Max by relying on the pattr and pattrstorage objects to send messages 
around. Probably a bit slower, but it ended up being much cleaner.



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



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

Re: [PD] How's Pd limited?

[patrice colet]

Le 23/02/2016 09:00, Roman Haefeli a écrit :


going to do when it dies? I'd love if Pd would provide some true
multi-threading (not like [pd~] which is tightly coupled to its parent).

Roman


That's a clever point I'm also sharing, but from informations grabbed in tcl 
documentation
that seem to imply a complete rewrite of the client:

Some consolidated rules for embedding Tcl in a threaded application:

 *

   You can*NEVER*use the same interpreter from more than one thread

 *

   If you only have one Tcl Interpreter:

 *

   You can use either Unthreaded or Threaded Tcl

 *

   No/Big Global Mutex/[ Big Global Mutex] 
is required for Unthreaded Tcl Build (Never required for 
Threaded Tcl build)

 *

   If you have Multiple Tcl Interpreters:

 *

   If you are using an Unthreaded Tcl/Big Global Mutex/[ 
Big Global Mutex] is 
required for*ALL*calls to functions in libtcl

 *

   If you are using a Threaded Tcl, no mutex locks are required

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

Re: [PD] How's Pd limited?

[Dan Wilcox]

> Em ter, 23 de fev de 2016 às 00:56, Matt Barber  > escreveu:
> Newest vanilla has basic object resize, which actually helps a lot with some 
> of the issues brought up here. It's also very helpful that comments can be 
> resized, so you can set the wrap point.
> 
> Cool.. I'm using pd 0.46-7, what's that object? :)

Hover your mouse over the right side of an object box and drag…


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

Re: [PD] How's Pd limited?

[IOhannes m zmoelnig]

On 2016-02-23 00:17, Jonathan Wilkes via Pd-list wrote:
> 
[...]

+1.



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

Re: [PD] How's Pd limited?

[IOhannes m zmoelnig]

On 2016-02-23 02:20, Morten Minothi Kristiansen wrote:
> Pd extended
> 0.43.

as you are undoubtedly aware (it has been stated so many times on ths
list), Pd-extended is unmaintained for a couple of years and for all
practical issues to be considered dead.

please use Pd-vanilla.


fgmasdr
IOhannes



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

Re: [PD] How's Pd limited?

[Roman Haefeli]

On Mon, 2016-02-22 at 01:19 -0800, Eugene Lazarchik wrote:
> Where do I start?

Thanks. That is a pretty comprehensive list, though I do not agree with
all your points (ugly look, mailing list, big patches become unreadable
fast). For me the most important point is still missing.

* Since Pure Data aims to be a realtime / live application, I am missing
most that I cannot do some actions without interrupting audio.
Everything that touches the DSP graph is a no-go. There's a way around
many things that touch DSP graph (never resize arrays used in DSP, for
instance). But not being able load patches without interrupting audio is
the most limiting factor for me. 

* The world of CPUs has shifted focus from single-threading performance
to many cores and power efficiency. It seems it's getting harder finding
a device with a single-threading performance as good as my 8-year old
laptop. And I'm easily saturating that one with my Pd stuff. What am I
going to do when it dies? I'd love if Pd would provide some true
multi-threading (not like [pd~] which is tightly coupled to its parent).

Roman


> * Dynamic patching is officially not supported and bug/feature
> requests get ignored. I had to jump through a lot of hoops to use
> dynamic patching with GOP but I discovered a bunch of weird issues
> with subpatches not getting redrawn and connectors left hanging after
> object deletion. Had to build ugly hacks/workarounds since nobody's
> gonna fix the issues in PD. Sending loadbangs to dynamically created
> objects is a pain, as well as trying to dynamically connect them to
> something (most examples of using the "connect" message use hardcoded
> object ID's).
> 
> * Support for lists is quite limited. Wanna create a multidimentional
> array? Build your own. Want a hash map? Build your own. Luckily
> there's list-abs but it's weird that such basic functionality (that's
> present in most programming languages) is not a core language feature.
> 
> * Sends and receives are global which creates a potential for
> conflicts. $0 can be used to avoid that but it looks ugly and many
> libraries, patches, and I think even help files, don't use it.
> 
> * Help files are *.pd which sounds neat at first, until you realize
> that they're not easily searchable and can't be viewed online.
> 
> * Bugs and weird behavior when handling special characters. There's no
> consistent way of escaping them. Sometimes characters disappear when
> saving and loading a patch.
> 
> * Limited support for comments. Special characters are not allowed
> (really? these are comments!). Automatic line wrapping doesn't work
> well since after saving/loading a patch often changes how text is
> broken into lines. So I have to put each line as a separate comment.
> 
> * Dependence on font sizes. By default object boxes scale
> automatically depending on the text inside. When you add more text,
> all inlets/outlets move. I installed a different version of PD and
> font size is slightly different and all objects are of a different
> size now.* Want to add an outlet to the beginning of a trigger object?
> Enjoy disconnecting and connecting all other outlets since there's no
> way of automatically move them.
> 
> * Want to print all messages flowing through a connection for
> debugging purposes? Remove the connection, then create a [t a a]
> object, then create a [print] object, then connect [print] to the
> second outlet, then connect [t a a] to the previous and next object
> (If you don't use the [trigger], messages will only be printed after
> they flow through the whole system). After you're done, delete the
> objects and re-create the connection. Not very convenient for quick
> debugging.
> 
> * Vanilla provides only minimal functionality while most of the
> convenient objects are supposed to come from external libraries.
> There's multiple issues with that. First one is that libraries are
> less standardized and consistent. They have different approaches,
> sometimes duplicate each other, use different conventions for naming,
> inlets/outlets, etc. Second issue is that libraries often become
> dead/unmaintained.
> 
> * Big patches/abstractions become unreadable really fast. Connectors
> are always straight lines and there's no support for dummy
> intermediate "points" for connecting stuff. I use [t a] and [+~] for
> these purposes but it'd be nice to have native support for this.
> 
> * Standard GUI objects are ugly and have limited functionality.
> * There's no good support for the concept of functions/procedures.
> Let's say we need to take some input, do some transformations and
> produce output, and we need to do that in multiple places in our
> patch. We can copy the objects but that will make the patch use more
> memory and there will be no code reuse. Another way is to make that an
> abstraction, but it's silly to make abstractions for every little
> thing that we need in 2 places. Also, instantiating 2 abstractions
> still uses more memory. We can try 

Re: [PD] How's Pd limited?

[William Huston]

My answer is in the form of a Koan:


*If an oscillator's output is not connected to a DAC,*
*does it still make a sound? *

On Sun, Feb 21, 2016 at 8:49 PM, Matti Viljamaa  wrote:

> Perhaps a bit of broad question, but I find it interesting in order to
> speculate about future additions.
>
> How do you think Pure Data is limited?
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>



-- 
--
May you, and all beings
be happy and free from suffering :)
-- ancient Buddhist Prayer (Metta)
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] How's Pd limited?

[Esteban Viveros]

I found that:
http://forum.pdpatchrepo.info/topic/9749/question-resize-canvas-realtime/4


Em ter, 23 de fev de 2016 às 03:22, Esteban Viveros 
escreveu:

> Em ter, 23 de fev de 2016 às 00:56, Matt Barber 
> escreveu:
>
>> Newest vanilla has basic object resize, which actually helps a lot with
>> some of the issues brought up here. It's also very helpful that comments
>> can be resized, so you can set the wrap point.
>>
>> Cool.. I'm using pd 0.46-7, what's that object? :)
>
>
>> On Mon, Feb 22, 2016 at 10:48 PM, Esteban Viveros 
>> wrote:
>>
>>> A feature I miss in vanilla and extended (pdl2ork solve that) is resize
>>> objects via one point click and drag. If it is hard to implement, a "apply"
>>> button on properties can help to design UI's in Vanilla.
>>>
>>> Max have features like auto-align horizontally/vertically and align and
>>> route patch cords which is very useful to organize patch cords and make the
>>> thinks more readable. I like them a lot.
>>>
>>> Em seg, 22 de fev de 2016 às 23:49, Johnny Mauser via Pd-list <
>>> pd-list@lists.iem.at> escreveu:
>>>
 That's something i completly experiece diffrently!! Pd fucks up in
 practise and development quiet often (maybe i make it fuck up) but once it
 runs, it runs stable every time!!

 Love to pd,

 Johnny
 Am 23.02.2016 02:20 schrieb "Morten Minothi Kristiansen" <
 mino...@gmail.com>:

> Not tried different builds, please giide me.
> 23. feb. 2016 02.20 skrev "Morten Minothi Kristiansen" <
> mino...@gmail.com>:
>
>> Its been like this with Mavericks, Yosemite and El capitalist. Pd
>> extended 0.43. I did a clean install a week ago and it worked fine for a
>> week until I installed live 9. It still worked until it suddenly hit some
>> kond of wall again.
>>
>> Mort
>> 23. feb. 2016 02.15 skrev "AP Vague" :
>>
>>> Woah, that's definitely a problem I haven't heard of... I'm guessing
>>> you've already tried using different builds. What OS are you on?
>>>
>>> On Mon, Feb 22, 2016 at 7:07 PM, Morten Minothi Kristiansen <
>>> mino...@gmail.com> wrote:
>>>
 On my last two comouters PD wont open unless I start it with a
 standalone patch I made long ago. It works for a little while, then 
 crashes
 completely and for ever more...unless I use the stand alone. 
 Recently...5
 min before a gig the standalone wouldnt even start. The gig was fine 
 as Im
 nott 100% relying on pd, but I have lost faith in PD EXTENDED and wish
 someone could have helped me earlier with this. I have posted and 
 searched
 for answears, but didnt get nothing back. Aaaarrrhhh!!!

 I would mayyybe make a few more attempts if only someone serious
 would help me out with this and fix the problem, but thats yet to be 
 the
 case.

 Ok... sorry about the rant. Had to get it out and now Im moving on
 with Max.

 Yebo
 Morten
 22. feb. 2016 02.52 skrev "Matti Viljamaa" :

> Perhaps a bit of broad question, but I find it interesting in
> order to speculate about future additions.
>
> How do you think Pure Data is limited?
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>

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


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

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

Re: [PD] How's Pd limited?

[Esteban Viveros]

Em ter, 23 de fev de 2016 às 00:56, Matt Barber 
escreveu:

> Newest vanilla has basic object resize, which actually helps a lot with
> some of the issues brought up here. It's also very helpful that comments
> can be resized, so you can set the wrap point.
>
> Cool.. I'm using pd 0.46-7, what's that object? :)


> On Mon, Feb 22, 2016 at 10:48 PM, Esteban Viveros 
> wrote:
>
>> A feature I miss in vanilla and extended (pdl2ork solve that) is resize
>> objects via one point click and drag. If it is hard to implement, a "apply"
>> button on properties can help to design UI's in Vanilla.
>>
>> Max have features like auto-align horizontally/vertically and align and
>> route patch cords which is very useful to organize patch cords and make the
>> thinks more readable. I like them a lot.
>>
>> Em seg, 22 de fev de 2016 às 23:49, Johnny Mauser via Pd-list <
>> pd-list@lists.iem.at> escreveu:
>>
>>> That's something i completly experiece diffrently!! Pd fucks up in
>>> practise and development quiet often (maybe i make it fuck up) but once it
>>> runs, it runs stable every time!!
>>>
>>> Love to pd,
>>>
>>> Johnny
>>> Am 23.02.2016 02:20 schrieb "Morten Minothi Kristiansen" <
>>> mino...@gmail.com>:
>>>
 Not tried different builds, please giide me.
 23. feb. 2016 02.20 skrev "Morten Minothi Kristiansen" <
 mino...@gmail.com>:

> Its been like this with Mavericks, Yosemite and El capitalist. Pd
> extended 0.43. I did a clean install a week ago and it worked fine for a
> week until I installed live 9. It still worked until it suddenly hit some
> kond of wall again.
>
> Mort
> 23. feb. 2016 02.15 skrev "AP Vague" :
>
>> Woah, that's definitely a problem I haven't heard of... I'm guessing
>> you've already tried using different builds. What OS are you on?
>>
>> On Mon, Feb 22, 2016 at 7:07 PM, Morten Minothi Kristiansen <
>> mino...@gmail.com> wrote:
>>
>>> On my last two comouters PD wont open unless I start it with a
>>> standalone patch I made long ago. It works for a little while, then 
>>> crashes
>>> completely and for ever more...unless I use the stand alone. 
>>> Recently...5
>>> min before a gig the standalone wouldnt even start. The gig was fine as 
>>> Im
>>> nott 100% relying on pd, but I have lost faith in PD EXTENDED and wish
>>> someone could have helped me earlier with this. I have posted and 
>>> searched
>>> for answears, but didnt get nothing back. Aaaarrrhhh!!!
>>>
>>> I would mayyybe make a few more attempts if only someone serious
>>> would help me out with this and fix the problem, but thats yet to be the
>>> case.
>>>
>>> Ok... sorry about the rant. Had to get it out and now Im moving on
>>> with Max.
>>>
>>> Yebo
>>> Morten
>>> 22. feb. 2016 02.52 skrev "Matti Viljamaa" :
>>>
 Perhaps a bit of broad question, but I find it interesting in order
 to speculate about future additions.

 How do you think Pure Data is limited?
 ___
 Pd-list@lists.iem.at mailing list
 UNSUBSCRIBE and account-management ->
 http://lists.puredata.info/listinfo/pd-list

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

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

Re: [PD] How's Pd limited?

[Esteban Viveros]

Like that:

Align: https://youtu.be/lCIeIelbw74
Route Patch Cords: https://youtu.be/2u_UJQ8OfvU



Em ter, 23 de fev de 2016 às 02:09, Jonathan Wilkes 
escreveu:

> > Here's a radical idea that I've sometimes pondered: what if we could
> create left-inlets and right-outlets as well as the standard top- and
> bottom- ones?
>
> If the object has more than one inlet or outlet you wouldn't be able to
> fit them on the side of the object box.
>
> Also, you run into a common UI problem: if you rotate a thing ninety
> degrees, do you rotate clockwise or counterclockwise?  If I push "up"
> on a DirectTv remote the channel guide on the screen scrolls down (and the
> numbers decrease!), but if I slide my fingers up a MacBook
> touchpad the browser window scrolls upward.  Similarly, vertically-placed
> outlets could fire top-down or bottom-up.  Maybe one is somehow
> more natural than the other, but off the top of my head I can't think
> which.  So I think you'd get more conceptual complexity in return for
> visual left-to-right flow.
>
> [expr] helps to fill the role you describe.  Unfortunately the
> Max-compatibility creates more complexity, making Pd's mantra of
> "everything is a float" turn into "everything is a float unless it follows
> the syntax of that other software which you may or may
> not have learned..."
>
> -Jonathan
>
>
>
> On Monday, February 22, 2016 11:40 PM, Jonathan Wilkes 
> wrote:
>
>
> > Max have features like auto-align horizontally/vertically
>
> Pd-l2ork has this, too-- "Tidy Up" in the Edit menu.  It's a little
> strange-- if you click it once it will sweep the selected objects into a
> "pile", and if you click again it will fan them out like a deck of cards.
> But it can work well for some situations.
>
> > and align and route patch cords which is very useful to organize patch
> cords and make the thinks more readable. I like them a lot.
>
> That's a side-effect of "Tidy Up" in a lot of cases, at least for the
> leftmost inlets and outlets.
>
> -Jonathan
>
>
>
> On Monday, February 22, 2016 10:49 PM, Esteban Viveros <
> emvive...@gmail.com> wrote:
>
>
> A feature I miss in vanilla and extended (pdl2ork solve that) is resize
> objects via one point click and drag. If it is hard to implement, a "apply"
> button on properties can help to design UI's in Vanilla.
>
> Max have features like auto-align horizontally/vertically and align and
> route patch cords which is very useful to organize patch cords and make the
> thinks more readable. I like them a lot.
>
> Em seg, 22 de fev de 2016 às 23:49, Johnny Mauser via Pd-list <
> pd-list@lists.iem.at> escreveu:
>
> That's something i completly experiece diffrently!! Pd fucks up in
> practise and development quiet often (maybe i make it fuck up) but once it
> runs, it runs stable every time!!
> Love to pd,
> Johnny
> Am 23.02.2016 02:20 schrieb "Morten Minothi Kristiansen" <
> mino...@gmail.com>:
>
> Not tried different builds, please giide me.
> 23. feb. 2016 02.20 skrev "Morten Minothi Kristiansen"  >:
>
> Its been like this with Mavericks, Yosemite and El capitalist. Pd extended
> 0.43. I did a clean install a week ago and it worked fine for a week until
> I installed live 9. It still worked until it suddenly hit some kond of wall
> again.
> Mort
> 23. feb. 2016 02.15 skrev "AP Vague" :
>
> Woah, that's definitely a problem I haven't heard of... I'm guessing
> you've already tried using different builds. What OS are you on?
>
> On Mon, Feb 22, 2016 at 7:07 PM, Morten Minothi Kristiansen <
> mino...@gmail.com> wrote:
>
> On my last two comouters PD wont open unless I start it with a standalone
> patch I made long ago. It works for a little while, then crashes completely
> and for ever more...unless I use the stand alone. Recently...5 min before a
> gig the standalone wouldnt even start. The gig was fine as Im nott 100%
> relying on pd, but I have lost faith in PD EXTENDED and wish someone could
> have helped me earlier with this. I have posted and searched for answears,
> but didnt get nothing back. Aaaarrrhhh!!!
> I would mayyybe make a few more attempts if only someone serious would
> help me out with this and fix the problem, but thats yet to be the case.
> Ok... sorry about the rant. Had to get it out and now Im moving on with
> Max.
> Yebo
> Morten
> 22. feb. 2016 02.52 skrev "Matti Viljamaa" :
>
> Perhaps a bit of broad question, but I find it interesting in order to
> speculate about future additions.
>
> How do you think Pure Data is limited?
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
>
> 

Re: [PD] How's Pd limited?

[Jonathan Wilkes via Pd-list]

> Here's a radical idea that I've sometimes pondered: what if we could create 
>left-inlets and right-outlets as well as the standard top- and bottom- ones? 
If the object has more than one inlet or outlet you wouldn't be able to fit 
them on the side of the object box.
Also, you run into a common UI problem: if you rotate a thing ninety degrees, 
do you rotate clockwise or counterclockwise?  If I push "up" on a DirectTv 
remote the channel guide on the screen scrolls down (and the numbers 
decrease!), but if I slide my fingers up a MacBook touchpad the browser window 
scrolls upward.  Similarly, vertically-placed outlets could fire top-down or 
bottom-up.  Maybe one is somehow more natural than the other, but off the top 
of my head I can't think which.  So I think you'd get more conceptual 
complexity in return for visual left-to-right flow.
[expr] helps to fill the role you describe.  Unfortunately the 
Max-compatibility creates more complexity, making Pd's mantra of "everything is 
a float" turn into "everything is a float unless it follows the syntax of that 
other software which you may or may not have learned..."
-Jonathan


On Monday, February 22, 2016 11:40 PM, Jonathan Wilkes  
wrote:
 

 > Max have features like auto-align horizontally/vertically
Pd-l2ork has this, too-- "Tidy Up" in the Edit menu.  It's a little strange-- 
if you click it once it will sweep the selected objects into a "pile", and if 
you click again it will fan them out like a deck of cards.  But it can work 
well for some situations.
> and align and route patch cords which is very useful to organize patch cords 
> and make the thinks more readable. I like them a lot.
That's a side-effect of "Tidy Up" in a lot of cases, at least for the leftmost 
inlets and outlets.
-Jonathan
 

On Monday, February 22, 2016 10:49 PM, Esteban Viveros 
 wrote:
 

 A feature I miss in vanilla and extended (pdl2ork solve that) is resize 
objects via one point click and drag. If it is hard to implement, a "apply" 
button on properties can help to design UI's in Vanilla.
Max have features like auto-align horizontally/vertically and align and route 
patch cords which is very useful to organize patch cords and make the thinks 
more readable. I like them a lot.
Em seg, 22 de fev de 2016 às 23:49, Johnny Mauser via Pd-list 
 escreveu:

That's something i completly experiece diffrently!! Pd fucks up in practise and 
development quiet often (maybe i make it fuck up) but once it runs, it runs 
stable every time!!Love to pd, Johnny Am 23.02.2016 02:20 schrieb "Morten 
Minothi Kristiansen" :

Not tried different builds, please giide me.23. feb. 2016 02.20 skrev "Morten 
Minothi Kristiansen" :

Its been like this with Mavericks, Yosemite and El capitalist. Pd extended 
0.43. I did a clean install a week ago and it worked fine for a week until I 
installed live 9. It still worked until it suddenly hit some kond of wall 
again.Mort23. feb. 2016 02.15 skrev "AP Vague" :

Woah, that's definitely a problem I haven't heard of... I'm guessing you've 
already tried using different builds. What OS are you on?
On Mon, Feb 22, 2016 at 7:07 PM, Morten Minothi Kristiansen  
wrote:

On my last two comouters PD wont open unless I start it with a standalone patch 
I made long ago. It works for a little while, then crashes completely and for 
ever more...unless I use the stand alone. Recently...5 min before a gig the 
standalone wouldnt even start. The gig was fine as Im nott 100% relying on pd, 
but I have lost faith in PD EXTENDED and wish someone could have helped me 
earlier with this. I have posted and searched for answears, but didnt get 
nothing back. Aaaarrrhhh!!! I would mayyybe make a few more attempts if 
only someone serious would help me out with this and fix the problem, but thats 
yet to be the case. Ok... sorry about the rant. Had to get it out and now Im 
moving on with Max. Yebo
Morten 22. feb. 2016 02.52 skrev "Matti Viljamaa" :

Perhaps a bit of broad question, but I find it interesting in order to 
speculate about future additions.

How do you think Pure Data is limited?
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list


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






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


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


___

Re: [PD] How's Pd limited?

[Jonathan Wilkes via Pd-list]

> Max have features like auto-align horizontally/vertically
Pd-l2ork has this, too-- "Tidy Up" in the Edit menu.  It's a little strange-- 
if you click it once it will sweep the selected objects into a "pile", and if 
you click again it will fan them out like a deck of cards.  But it can work 
well for some situations.
> and align and route patch cords which is very useful to organize patch cords 
> and make the thinks more readable. I like them a lot.
That's a side-effect of "Tidy Up" in a lot of cases, at least for the leftmost 
inlets and outlets.
-Jonathan
 

On Monday, February 22, 2016 10:49 PM, Esteban Viveros 
 wrote:
 

 A feature I miss in vanilla and extended (pdl2ork solve that) is resize 
objects via one point click and drag. If it is hard to implement, a "apply" 
button on properties can help to design UI's in Vanilla.
Max have features like auto-align horizontally/vertically and align and route 
patch cords which is very useful to organize patch cords and make the thinks 
more readable. I like them a lot.
Em seg, 22 de fev de 2016 às 23:49, Johnny Mauser via Pd-list 
 escreveu:

That's something i completly experiece diffrently!! Pd fucks up in practise and 
development quiet often (maybe i make it fuck up) but once it runs, it runs 
stable every time!!Love to pd, Johnny Am 23.02.2016 02:20 schrieb "Morten 
Minothi Kristiansen" :

Not tried different builds, please giide me.23. feb. 2016 02.20 skrev "Morten 
Minothi Kristiansen" :

Its been like this with Mavericks, Yosemite and El capitalist. Pd extended 
0.43. I did a clean install a week ago and it worked fine for a week until I 
installed live 9. It still worked until it suddenly hit some kond of wall 
again.Mort23. feb. 2016 02.15 skrev "AP Vague" :

Woah, that's definitely a problem I haven't heard of... I'm guessing you've 
already tried using different builds. What OS are you on?
On Mon, Feb 22, 2016 at 7:07 PM, Morten Minothi Kristiansen  
wrote:

On my last two comouters PD wont open unless I start it with a standalone patch 
I made long ago. It works for a little while, then crashes completely and for 
ever more...unless I use the stand alone. Recently...5 min before a gig the 
standalone wouldnt even start. The gig was fine as Im nott 100% relying on pd, 
but I have lost faith in PD EXTENDED and wish someone could have helped me 
earlier with this. I have posted and searched for answears, but didnt get 
nothing back. Aaaarrrhhh!!! I would mayyybe make a few more attempts if 
only someone serious would help me out with this and fix the problem, but thats 
yet to be the case. Ok... sorry about the rant. Had to get it out and now Im 
moving on with Max. Yebo
Morten 22. feb. 2016 02.52 skrev "Matti Viljamaa" :

Perhaps a bit of broad question, but I find it interesting in order to 
speculate about future additions.

How do you think Pure Data is limited?
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list


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






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


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


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


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

Re: [PD] How's Pd limited?

[Dan Wilcox]

> On Feb 22, 2016, at 8:54 PM, pd-list-requ...@lists.iem.at wrote:
> 
> From: Esteban Viveros <emvive...@gmail.com <mailto:emvive...@gmail.com>>
> Subject: Re: [PD] How's Pd limited?
> Date: February 22, 2016 at 8:48:16 PM MST
> To: Johnny Mauser <joson.andr...@googlemail.com 
> <mailto:joson.andr...@googlemail.com>>, Morten Minothi Kristiansen 
> <mino...@gmail.com <mailto:mino...@gmail.com>>
> Cc: pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>
> 
> 
> A feature I miss in vanilla and extended (pdl2ork solve that) is resize 
> objects via one point click and drag. If it is hard to implement, a "apply" 
> button on properties can help to design UI's in Vanilla.

I have updates in the works for the vanilla dialog boxes.

> Max have features like auto-align horizontally/vertically and align and route 
> patch cords which is very useful to organize patch cords and make the thinks 
> more readable. I like them a lot.

Object & canvas align could be made using a GUI plugin. Such a plugin might 
exist already, actually.


Dan Wilcox
@danomatika <https://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] How's Pd limited?

[Dan Wilcox]

If you’re on Mac OS X, you problem might be related to this: 
http://puredata.info/docs/faq/help-pd-crashes-on-startup-on-mac-osx-10-7 
<http://puredata.info/docs/faq/help-pd-crashes-on-startup-on-mac-osx-10-7>


Dan Wilcox
@danomatika <https://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
> On Feb 22, 2016, at 6:20 PM, pd-list-requ...@lists.iem.at wrote:
> 
> From: Morten Minothi Kristiansen <mino...@gmail.com 
> <mailto:mino...@gmail.com>>
> Subject: Re: [PD] How's Pd limited?
> Date: February 22, 2016 at 6:07:16 PM MST
> To: Matti Viljamaa <mvilja...@kapsi.fi <mailto:mvilja...@kapsi.fi>>
> Cc: Pd-List <pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>>
> 
> 
> On my last two comouters PD wont open unless I start it with a standalone 
> patch I made long ago. It works for a little while, then crashes completely 
> and for ever more...unless I use the stand alone. Recently...5 min before a 
> gig the standalone wouldnt even start. The gig was fine as Im nott 100% 
> relying on pd, but I have lost faith in PD EXTENDED and wish someone could 
> have helped me earlier with this. I have posted and searched for answears, 
> but didnt get nothing back. Aaaarrrhhh!!! 
> 
> I would mayyybe make a few more attempts if only someone serious would help 
> me out with this and fix the problem, but thats yet to be the case. 
> 
> Ok... sorry about the rant. Had to get it out and now Im moving on with Max. 
> 
> Yebo
> Morten
> 

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

Re: [PD] How's Pd limited?

[Matt Barber]

Newest vanilla has basic object resize, which actually helps a lot with
some of the issues brought up here. It's also very helpful that comments
can be resized, so you can set the wrap point.

On Mon, Feb 22, 2016 at 10:48 PM, Esteban Viveros 
wrote:

> A feature I miss in vanilla and extended (pdl2ork solve that) is resize
> objects via one point click and drag. If it is hard to implement, a "apply"
> button on properties can help to design UI's in Vanilla.
>
> Max have features like auto-align horizontally/vertically and align and
> route patch cords which is very useful to organize patch cords and make the
> thinks more readable. I like them a lot.
>
> Em seg, 22 de fev de 2016 às 23:49, Johnny Mauser via Pd-list <
> pd-list@lists.iem.at> escreveu:
>
>> That's something i completly experiece diffrently!! Pd fucks up in
>> practise and development quiet often (maybe i make it fuck up) but once it
>> runs, it runs stable every time!!
>>
>> Love to pd,
>>
>> Johnny
>> Am 23.02.2016 02:20 schrieb "Morten Minothi Kristiansen" <
>> mino...@gmail.com>:
>>
>>> Not tried different builds, please giide me.
>>> 23. feb. 2016 02.20 skrev "Morten Minothi Kristiansen" <
>>> mino...@gmail.com>:
>>>
 Its been like this with Mavericks, Yosemite and El capitalist. Pd
 extended 0.43. I did a clean install a week ago and it worked fine for a
 week until I installed live 9. It still worked until it suddenly hit some
 kond of wall again.

 Mort
 23. feb. 2016 02.15 skrev "AP Vague" :

> Woah, that's definitely a problem I haven't heard of... I'm guessing
> you've already tried using different builds. What OS are you on?
>
> On Mon, Feb 22, 2016 at 7:07 PM, Morten Minothi Kristiansen <
> mino...@gmail.com> wrote:
>
>> On my last two comouters PD wont open unless I start it with a
>> standalone patch I made long ago. It works for a little while, then 
>> crashes
>> completely and for ever more...unless I use the stand alone. Recently...5
>> min before a gig the standalone wouldnt even start. The gig was fine as 
>> Im
>> nott 100% relying on pd, but I have lost faith in PD EXTENDED and wish
>> someone could have helped me earlier with this. I have posted and 
>> searched
>> for answears, but didnt get nothing back. Aaaarrrhhh!!!
>>
>> I would mayyybe make a few more attempts if only someone serious
>> would help me out with this and fix the problem, but thats yet to be the
>> case.
>>
>> Ok... sorry about the rant. Had to get it out and now Im moving on
>> with Max.
>>
>> Yebo
>> Morten
>> 22. feb. 2016 02.52 skrev "Matti Viljamaa" :
>>
>>> Perhaps a bit of broad question, but I find it interesting in order
>>> to speculate about future additions.
>>>
>>> How do you think Pure Data is limited?
>>> ___
>>> Pd-list@lists.iem.at mailing list
>>> UNSUBSCRIBE and account-management ->
>>> http://lists.puredata.info/listinfo/pd-list
>>>
>>
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>>
>
>>> ___
>>> Pd-list@lists.iem.at mailing list
>>> UNSUBSCRIBE and account-management ->
>>> http://lists.puredata.info/listinfo/pd-list
>>>
>>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] How's Pd limited?

[Esteban Viveros]

A feature I miss in vanilla and extended (pdl2ork solve that) is resize
objects via one point click and drag. If it is hard to implement, a "apply"
button on properties can help to design UI's in Vanilla.

Max have features like auto-align horizontally/vertically and align and
route patch cords which is very useful to organize patch cords and make the
thinks more readable. I like them a lot.

Em seg, 22 de fev de 2016 às 23:49, Johnny Mauser via Pd-list <
pd-list@lists.iem.at> escreveu:

> That's something i completly experiece diffrently!! Pd fucks up in
> practise and development quiet often (maybe i make it fuck up) but once it
> runs, it runs stable every time!!
>
> Love to pd,
>
> Johnny
> Am 23.02.2016 02:20 schrieb "Morten Minothi Kristiansen" <
> mino...@gmail.com>:
>
>> Not tried different builds, please giide me.
>> 23. feb. 2016 02.20 skrev "Morten Minothi Kristiansen" > >:
>>
>>> Its been like this with Mavericks, Yosemite and El capitalist. Pd
>>> extended 0.43. I did a clean install a week ago and it worked fine for a
>>> week until I installed live 9. It still worked until it suddenly hit some
>>> kond of wall again.
>>>
>>> Mort
>>> 23. feb. 2016 02.15 skrev "AP Vague" :
>>>
 Woah, that's definitely a problem I haven't heard of... I'm guessing
 you've already tried using different builds. What OS are you on?

 On Mon, Feb 22, 2016 at 7:07 PM, Morten Minothi Kristiansen <
 mino...@gmail.com> wrote:

> On my last two comouters PD wont open unless I start it with a
> standalone patch I made long ago. It works for a little while, then 
> crashes
> completely and for ever more...unless I use the stand alone. Recently...5
> min before a gig the standalone wouldnt even start. The gig was fine as Im
> nott 100% relying on pd, but I have lost faith in PD EXTENDED and wish
> someone could have helped me earlier with this. I have posted and searched
> for answears, but didnt get nothing back. Aaaarrrhhh!!!
>
> I would mayyybe make a few more attempts if only someone serious would
> help me out with this and fix the problem, but thats yet to be the case.
>
> Ok... sorry about the rant. Had to get it out and now Im moving on
> with Max.
>
> Yebo
> Morten
> 22. feb. 2016 02.52 skrev "Matti Viljamaa" :
>
>> Perhaps a bit of broad question, but I find it interesting in order
>> to speculate about future additions.
>>
>> How do you think Pure Data is limited?
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>

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

Re: [PD] How's Pd limited?

[Alexandre Torres Porres]

for extended, I recommend 0.42-5, but ideal is to try vanilla and use the
extended libraries you actually need

2016-02-23 0:45 GMT-03:00 Alexandre Torres Porres :

> forget about pd extended 0.43, I never recommend it !!!
>
> 2016-02-22 22:20 GMT-03:00 Morten Minothi Kristiansen :
>
>> Not tried different builds, please giide me.
>> 23. feb. 2016 02.20 skrev "Morten Minothi Kristiansen" > >:
>>
>>> Its been like this with Mavericks, Yosemite and El capitalist. Pd
>>> extended 0.43. I did a clean install a week ago and it worked fine for a
>>> week until I installed live 9. It still worked until it suddenly hit some
>>> kond of wall again.
>>>
>>> Mort
>>> 23. feb. 2016 02.15 skrev "AP Vague" :
>>>
 Woah, that's definitely a problem I haven't heard of... I'm guessing
 you've already tried using different builds. What OS are you on?

 On Mon, Feb 22, 2016 at 7:07 PM, Morten Minothi Kristiansen <
 mino...@gmail.com> wrote:

> On my last two comouters PD wont open unless I start it with a
> standalone patch I made long ago. It works for a little while, then 
> crashes
> completely and for ever more...unless I use the stand alone. Recently...5
> min before a gig the standalone wouldnt even start. The gig was fine as Im
> nott 100% relying on pd, but I have lost faith in PD EXTENDED and wish
> someone could have helped me earlier with this. I have posted and searched
> for answears, but didnt get nothing back. Aaaarrrhhh!!!
>
> I would mayyybe make a few more attempts if only someone serious would
> help me out with this and fix the problem, but thats yet to be the case.
>
> Ok... sorry about the rant. Had to get it out and now Im moving on
> with Max.
>
> Yebo
> Morten
> 22. feb. 2016 02.52 skrev "Matti Viljamaa" :
>
>> Perhaps a bit of broad question, but I find it interesting in order
>> to speculate about future additions.
>>
>> How do you think Pure Data is limited?
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>

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

Re: [PD] How's Pd limited?

[Alexandre Torres Porres]

forget about pd extended 0.43, I never recommend it !!!

2016-02-22 22:20 GMT-03:00 Morten Minothi Kristiansen :

> Not tried different builds, please giide me.
> 23. feb. 2016 02.20 skrev "Morten Minothi Kristiansen"  >:
>
>> Its been like this with Mavericks, Yosemite and El capitalist. Pd
>> extended 0.43. I did a clean install a week ago and it worked fine for a
>> week until I installed live 9. It still worked until it suddenly hit some
>> kond of wall again.
>>
>> Mort
>> 23. feb. 2016 02.15 skrev "AP Vague" :
>>
>>> Woah, that's definitely a problem I haven't heard of... I'm guessing
>>> you've already tried using different builds. What OS are you on?
>>>
>>> On Mon, Feb 22, 2016 at 7:07 PM, Morten Minothi Kristiansen <
>>> mino...@gmail.com> wrote:
>>>
 On my last two comouters PD wont open unless I start it with a
 standalone patch I made long ago. It works for a little while, then crashes
 completely and for ever more...unless I use the stand alone. Recently...5
 min before a gig the standalone wouldnt even start. The gig was fine as Im
 nott 100% relying on pd, but I have lost faith in PD EXTENDED and wish
 someone could have helped me earlier with this. I have posted and searched
 for answears, but didnt get nothing back. Aaaarrrhhh!!!

 I would mayyybe make a few more attempts if only someone serious would
 help me out with this and fix the problem, but thats yet to be the case.

 Ok... sorry about the rant. Had to get it out and now Im moving on with
 Max.

 Yebo
 Morten
 22. feb. 2016 02.52 skrev "Matti Viljamaa" :

> Perhaps a bit of broad question, but I find it interesting in order to
> speculate about future additions.
>
> How do you think Pure Data is limited?
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>

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


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

Re: [PD] How's Pd limited?

[Johnny Mauser via Pd-list]

That's something i completly experiece diffrently!! Pd fucks up in practise
and development quiet often (maybe i make it fuck up) but once it runs, it
runs stable every time!!

Love to pd,

Johnny
Am 23.02.2016 02:20 schrieb "Morten Minothi Kristiansen" :

> Not tried different builds, please giide me.
> 23. feb. 2016 02.20 skrev "Morten Minothi Kristiansen"  >:
>
>> Its been like this with Mavericks, Yosemite and El capitalist. Pd
>> extended 0.43. I did a clean install a week ago and it worked fine for a
>> week until I installed live 9. It still worked until it suddenly hit some
>> kond of wall again.
>>
>> Mort
>> 23. feb. 2016 02.15 skrev "AP Vague" :
>>
>>> Woah, that's definitely a problem I haven't heard of... I'm guessing
>>> you've already tried using different builds. What OS are you on?
>>>
>>> On Mon, Feb 22, 2016 at 7:07 PM, Morten Minothi Kristiansen <
>>> mino...@gmail.com> wrote:
>>>
 On my last two comouters PD wont open unless I start it with a
 standalone patch I made long ago. It works for a little while, then crashes
 completely and for ever more...unless I use the stand alone. Recently...5
 min before a gig the standalone wouldnt even start. The gig was fine as Im
 nott 100% relying on pd, but I have lost faith in PD EXTENDED and wish
 someone could have helped me earlier with this. I have posted and searched
 for answears, but didnt get nothing back. Aaaarrrhhh!!!

 I would mayyybe make a few more attempts if only someone serious would
 help me out with this and fix the problem, but thats yet to be the case.

 Ok... sorry about the rant. Had to get it out and now Im moving on with
 Max.

 Yebo
 Morten
 22. feb. 2016 02.52 skrev "Matti Viljamaa" :

> Perhaps a bit of broad question, but I find it interesting in order to
> speculate about future additions.
>
> How do you think Pure Data is limited?
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>

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


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

Re: [PD] How's Pd limited?

[Morten Minothi Kristiansen]

Not tried different builds, please giide me.
23. feb. 2016 02.20 skrev "Morten Minothi Kristiansen" :

> Its been like this with Mavericks, Yosemite and El capitalist. Pd extended
> 0.43. I did a clean install a week ago and it worked fine for a week until
> I installed live 9. It still worked until it suddenly hit some kond of wall
> again.
>
> Mort
> 23. feb. 2016 02.15 skrev "AP Vague" :
>
>> Woah, that's definitely a problem I haven't heard of... I'm guessing
>> you've already tried using different builds. What OS are you on?
>>
>> On Mon, Feb 22, 2016 at 7:07 PM, Morten Minothi Kristiansen <
>> mino...@gmail.com> wrote:
>>
>>> On my last two comouters PD wont open unless I start it with a
>>> standalone patch I made long ago. It works for a little while, then crashes
>>> completely and for ever more...unless I use the stand alone. Recently...5
>>> min before a gig the standalone wouldnt even start. The gig was fine as Im
>>> nott 100% relying on pd, but I have lost faith in PD EXTENDED and wish
>>> someone could have helped me earlier with this. I have posted and searched
>>> for answears, but didnt get nothing back. Aaaarrrhhh!!!
>>>
>>> I would mayyybe make a few more attempts if only someone serious would
>>> help me out with this and fix the problem, but thats yet to be the case.
>>>
>>> Ok... sorry about the rant. Had to get it out and now Im moving on with
>>> Max.
>>>
>>> Yebo
>>> Morten
>>> 22. feb. 2016 02.52 skrev "Matti Viljamaa" :
>>>
 Perhaps a bit of broad question, but I find it interesting in order to
 speculate about future additions.

 How do you think Pure Data is limited?
 ___
 Pd-list@lists.iem.at mailing list
 UNSUBSCRIBE and account-management ->
 http://lists.puredata.info/listinfo/pd-list

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

Re: [PD] How's Pd limited?

[Morten Minothi Kristiansen]

Its been like this with Mavericks, Yosemite and El capitalist. Pd extended
0.43. I did a clean install a week ago and it worked fine for a week until
I installed live 9. It still worked until it suddenly hit some kond of wall
again.

Mort
23. feb. 2016 02.15 skrev "AP Vague" :

> Woah, that's definitely a problem I haven't heard of... I'm guessing
> you've already tried using different builds. What OS are you on?
>
> On Mon, Feb 22, 2016 at 7:07 PM, Morten Minothi Kristiansen <
> mino...@gmail.com> wrote:
>
>> On my last two comouters PD wont open unless I start it with a standalone
>> patch I made long ago. It works for a little while, then crashes completely
>> and for ever more...unless I use the stand alone. Recently...5 min before a
>> gig the standalone wouldnt even start. The gig was fine as Im nott 100%
>> relying on pd, but I have lost faith in PD EXTENDED and wish someone could
>> have helped me earlier with this. I have posted and searched for answears,
>> but didnt get nothing back. Aaaarrrhhh!!!
>>
>> I would mayyybe make a few more attempts if only someone serious would
>> help me out with this and fix the problem, but thats yet to be the case.
>>
>> Ok... sorry about the rant. Had to get it out and now Im moving on with
>> Max.
>>
>> Yebo
>> Morten
>> 22. feb. 2016 02.52 skrev "Matti Viljamaa" :
>>
>>> Perhaps a bit of broad question, but I find it interesting in order to
>>> speculate about future additions.
>>>
>>> How do you think Pure Data is limited?
>>> ___
>>> Pd-list@lists.iem.at mailing list
>>> UNSUBSCRIBE and account-management ->
>>> http://lists.puredata.info/listinfo/pd-list
>>>
>>
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] How's Pd limited?

[AP Vague]

Woah, that's definitely a problem I haven't heard of... I'm guessing you've
already tried using different builds. What OS are you on?

On Mon, Feb 22, 2016 at 7:07 PM, Morten Minothi Kristiansen <
mino...@gmail.com> wrote:

> On my last two comouters PD wont open unless I start it with a standalone
> patch I made long ago. It works for a little while, then crashes completely
> and for ever more...unless I use the stand alone. Recently...5 min before a
> gig the standalone wouldnt even start. The gig was fine as Im nott 100%
> relying on pd, but I have lost faith in PD EXTENDED and wish someone could
> have helped me earlier with this. I have posted and searched for answears,
> but didnt get nothing back. Aaaarrrhhh!!!
>
> I would mayyybe make a few more attempts if only someone serious would
> help me out with this and fix the problem, but thats yet to be the case.
>
> Ok... sorry about the rant. Had to get it out and now Im moving on with
> Max.
>
> Yebo
> Morten
> 22. feb. 2016 02.52 skrev "Matti Viljamaa" :
>
>> Perhaps a bit of broad question, but I find it interesting in order to
>> speculate about future additions.
>>
>> How do you think Pure Data is limited?
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] How's Pd limited?

[Morten Minothi Kristiansen]

On my last two comouters PD wont open unless I start it with a standalone
patch I made long ago. It works for a little while, then crashes completely
and for ever more...unless I use the stand alone. Recently...5 min before a
gig the standalone wouldnt even start. The gig was fine as Im nott 100%
relying on pd, but I have lost faith in PD EXTENDED and wish someone could
have helped me earlier with this. I have posted and searched for answears,
but didnt get nothing back. Aaaarrrhhh!!!

I would mayyybe make a few more attempts if only someone serious would help
me out with this and fix the problem, but thats yet to be the case.

Ok... sorry about the rant. Had to get it out and now Im moving on with
Max.

Yebo
Morten
22. feb. 2016 02.52 skrev "Matti Viljamaa" :

> Perhaps a bit of broad question, but I find it interesting in order to
> speculate about future additions.
>
> How do you think Pure Data is limited?
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] How's Pd limited?

[Jonathan Wilkes via Pd-list]

> It's just that the presence of those features makes it much easier not to 
> care, and many users just don't care, and it makes things worse for those of 
> us who have to use that patch elsewhere.
Short story: I'm not going to write the code to implement segmented cords, and 
I don't think anyone else is, either.  But if someone wants to I'll certainly 
have 
a look.
 
Long story:
Non-segmented patch cords suggest a flow chart.  Segmented patch cords-- 
when used sensibly-- suggest a circuit board.  The difference IMO is nobody in 
their right mind would suggest circuit boards are an especially readable and 
friendly way to elucidate a program's logic to human beings.  That's the 
starting 
premise of every "flow based" language, though, and I've never seen much 
evidence to back it up.

All those awful-looking yet functional Pd and Max patches get that way 
because of the strength of the approach, IMO-- that is, a physical motion with 
visual animated feedback creates the flow of data.  It's the drawing of the 
patch matters, not the engraving.
For example, imagine that Pd tracked Dan's eye movement on the first 
version of his patch.  Those objects and wires that he hasn't looked at for 
awhile fade more and more into the background, unless he tries to focus 
on one of them and then they return.  I think that's a pretty decent 
description 
of how we actually create those write-only patches.  Throw in whatever the 
opposite of MVC is (e.g., where a toggle can appear smack dab in the model), 
and you have an environment that's well suited to quick prototyping.
Of course that mental model has a short shelf-life, so there's the separate 
issue of how to turn that into a readable patch.  There are certainly patterns 
to follow there, and ways to minimize the spaghetti in the first place.  But I 
think that potential to draw big ugly lines across the whole damn thing is what 
drives the speed and elegance of developing in the language.  If it weren't 
then Pd 
would be like brainfuck, and none of those spaghetti patches would be able to 
deliver any functionality to speak of.
 
 So for those users who don't care about taking their patches (or, hopefully, 
small abstractions or subpatches) from 
"draw-time ugly-mode" to "presentable-to-other-humans mode", I don't think 
segmented cords matter much.  For the ones who do, I guess I'd rather look at 
a flow chart than a circuit board.  But given the choice I'd rather watch 
little 
gremlins carry buckets of water up a hill, or robots shooting lasers at drones. 
 
Or at least see the data "pumping" through all those boring control wires that 
seem to always obscure the text I'm trying to read...
-Jonathan



   

 On Monday, February 22, 2016 5:20 PM, Matt Barber  wrote:
 

 Hi all,
Forcing good practice is not something I'm interested in. Every programming 
language can be abused horribly (they even have a prize for best/worst abuse of 
C -- look through some of these http://www.ioccc.org/years.html ).
My point was not that avoiding segmented and hideable patch cords fixes these 
problems. It's just that the presence of those features makes it much easier 
not to care, and many users just don't care, and it makes things worse for 
those of us who have to use that patch elsewhere.
We did have a long list discussion about best practices, actually, collected 
here:
https://puredata.info/docs/style-guide/PrimordialStyleGuide/

There are other style guides too.
On Mon, Feb 22, 2016 at 4:29 PM, Dan Wilcox  wrote:



2016-02-22 17:25 GMT-03:00 Matt Barber :

I've said this before, but I think there are very good reasons not to ever 
include segmented patch cords (although hideable patch cords would be even 
worse). These two features are responsible for some of the very worst patching 
habits in Max/MSP. Have you ever been called on to run someone's patch, and you 
need to tweak something for your specific audio setup or fix a bug or whatever, 
and when you open it you get something that looks like this (one of the first 
"max patch" results on google image search):
http://www.letatoubleu.com/OLcomposer_files/image001.jpg


I agree, and I laugh when people say, this is hard to understand in Max, 
because of all the cords, I can't imagine how ugly it'd be in Pd.


The solution is the same in both environments: good use of encapsulation via 
subpatches & judicious use of send/recvs when necessary.
Example from robotcowboy:
* one of my first performance patches: 
https://www.flickr.com/photos/danomatika/25082084442/in/datetaken-public/* and 
the second version using subpatches & send/recvs: 
https://www.flickr.com/photos/danomatika/24573539133/in/datetaken-public/
This approach led to using GOP and modularizing things between separate patches 
& a main control patch: 
https://www.flickr.com/photos/danomatika/25107115651/in/datetaken-public/
To segment or not to segment is moot, you can create both well 

Re: [PD] How's Pd limited?

[Peter Nyboer]

I also dislike Send and Receive, but end up using them in pd. I don’t like that 
they are hard to keep track of (I see the receive, where’s the send?). I guess 
$0 does clear up the global issues, but it feels hacky. I managed to get rid of 
them in Max by relying on the pattr and pattrstorage objects to send messages 
around. Probably a bit slower, but it ended up being much cleaner.



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

Re: [PD] How's Pd limited?

[Dan Wilcox]

> On Feb 22, 2016, at 2:09 PM, pd-list-requ...@lists.iem.at wrote:
> 
> From: Eugene Lazarchik  >
> 
> I consider sends and receives evil. They're similar to global variables or 
> goto statements in general purpose programming languages.

However they are extremely useful when used well, especially in conjunction 
with $0. I don’t quite get the goto comparison here. Goto is a low level 
execution construct while send/receives is a higher level abstraction. I tech 
them as “named, invisible patch cords”.

> When you see a receive object, it's not obvious where all corresponding sends 
> may be. As opposed to simply following where the cords go.

The find menu is your friend here but of course one shouldn’t use send/receives 
for *everything*. I prefer to use patch chords as much as possible but their 
are times, especially when using GOP where send/receives make things not only 
more readable but *easier* to understand IMO. This, of course, is a style 
preference.

Also, libpd and both PdParty & PdDroidParty *rely* on send/receives for both 
inter app communication as well as  their UI implementations.

> Also, consider a subpatch (or abstraction), with certain cords connected to 
> it. In a way the inlets and outlets describe how this object can be used: it 
> can receive certain messages through inlets and then send output to the 
> outlets. But if there's sends and receives inside, it becomes much harder to 
> track what the object may do.

That’s a patching design issue and not a problem in the language/environment. 
If sends & receives are not used willy nilly, including ridiculous fanouts, 
there’s generally not too much of a problem, especially if a patch is 
documented.

> In regards to the screenshot: it could be simplified by putting stuff into 
> subpatches. However, even when there's only a couple of objects on a 
> subpatch, the cords can still cross the objects if there's no way to segment 
> them. Typical reasons include long objects ([pd 
> $0-descriptive-name-of-the-subpatch], or [t a a a a a a a a] or [route this 
> and that], etc.). Also it's hard to avoid a mess without segmenting if 
> there's a lot of feedback connections (when A's output is connected to B but 
> also B's output is connected to A).

This is usually fixed by arranging things in a good order underneath the [t a a 
a a a a a a] and subpatching and/or fanning things out. Not impossible to make 
things easy to understand without overlapping lines.

I’ve picked up quite a few tricks by looking at patches made by a number of 
people on this list. Maybe what we need is a wiki pages with examples of good 
patching practice?

Also, simple segmenting can be accomplished via using [t a] objects when 
desired. 

> Also, moving functionality in a subpatch usually should only be done when 
> there's something common between the objects inside and they implement a 
> relatively siloed functionality. Otherwise it may be hard to understand what 
> the subpatch is doing and the reader will have to constantly switch between 
> the parent and the subpatch to understand how they work together.

Again, this is a patching design issue. I agree that subpatches should only 
encapsulate common actions but not implementing things this way is a fault of 
the person who made the patch.

I have been using the method of adding descriptions to my subpatch as well as 
inlet/outlet objects as they aren’t used by help in documenting what’s going on:

[pd bass synth]

[inlet midi note vel pair]

[outlet~ pitched down audio]

etc


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

Re: [PD] How's Pd limited?

[Dan Wilcox]

> 2016-02-22 17:25 GMT-03:00 Matt Barber  >:
> I've said this before, but I think there are very good reasons not to ever 
> include segmented patch cords (although hideable patch cords would be even 
> worse). These two features are responsible for some of the very worst 
> patching habits in Max/MSP. Have you ever been called on to run someone's 
> patch, and you need to tweak something for your specific audio setup or fix a 
> bug or whatever, and when you open it you get something that looks like this 
> (one of the first "max patch" results on google image search):
> 
> http://www.letatoubleu.com/OLcomposer_files/image001.jpg 
> 
> 
> 
> I agree, and I laugh when people say, this is hard to understand in Max, 
> because of all the cords, I can't imagine how ugly it'd be in Pd.



The solution is the same in both environments: good use of encapsulation via 
subpatches & judicious use of send/recvs when necessary.

Example from robotcowboy:

* one of my first performance patches: 
https://www.flickr.com/photos/danomatika/25082084442/in/datetaken-public/ 

* and the second version using subpatches & send/recvs: 
https://www.flickr.com/photos/danomatika/24573539133/in/datetaken-public/ 


This approach led to using GOP and modularizing things between separate patches 
& a main control patch: 
https://www.flickr.com/photos/danomatika/25107115651/in/datetaken-public/ 


To segment or not to segment is moot, you can create both well designed as well 
as spaghetti patches in either environment just as you can create well-written 
or spaghetti code in any textual language. I agree that the environments are 
not at fault here.


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

Re: [PD] How's Pd limited?

[Niklas Reppel]

Hmm i'd say there's no way to force people to employ transparent, modular 
software 
design as long as you want to keep the language (whether it's patcher- or 
code-based)
somewhat flexible and powerful ... 

On Mon, Feb 22, 2016 at 09:03:16PM +, Jonathan Wilkes via Pd-list wrote:
> There are plenty of Pd patches just as unreadable.
> 
> When a large number of users are getting value out of code that unreadable, we
> need to ask more fundamental questions than
> whether the visual noise includes more or fewer right angles.
> 
> -Jonathan
> 
> 
> 
> On Monday, February 22, 2016 3:25 PM, Matt Barber  wrote:
> 
> 
> I've said this before, but I think there are very good reasons not to ever
> include segmented patch cords (although hideable patch cords would be even
> worse). These two features are responsible for some of the very worst patching
> habits in Max/MSP. Have you ever been called on to run someone's patch, and 
> you
> need to tweak something for your specific audio setup or fix a bug or 
> whatever,
> and when you open it you get something that looks like this (one of the first
> "max patch" results on google image search):
> 
> http://www.letatoubleu.com/OLcomposer_files/image001.jpg
> 
> If you can't bend the cords there's much less of a temptation to make these
> kinds of can-of-worms patches, and more of an incentive to use send/receive
> when you need to get a value into an inconvenient place. There's also an
> incentive to make things more modular, which is usually far easier to debug
> than a huge sprawling patch. So while I can see where they'd be very useful if
> used judiciously, as someone who often has to operate someone else's patches,
> I'm very hesitant.
> 
> 
> On Mon, Feb 22, 2016 at 3:05 PM, Jonathan Wilkes via Pd-list <
> pd-list@lists.iem.at> wrote:
> 
> Hi Eugene,
> Great post!
> 
> I help develop pd-l2ork, and it addresses some of the points below.  I
> recently got it building on OSX with most of the pd-extended libraries.
> 
> I'll reply to each point below...
> 
> > On Monday, February 22, 2016 4:21 AM, Eugene Lazarchik <
> evgenius.lazarc...@gmail.com> wrote:
> 
> 
> > Where do I start?
> 
> > * Dynamic patching is officially not supported and bug/feature requests
> get ignored. I had to jump through a lot of hoops to use dynamic patching
> with GOP but I discovered a bunch of weird issues with subpatches not
> getting redrawn and connectors left hanging after object deletion. Had to
> build ugly hacks/workarounds since nobody's gonna fix the issues in PD.
> Sending loadbangs to dynamically created objects is a pain, as well as
> trying to dynamically connect them to something (most examples of using 
> the
> "connect" message use hardcoded object ID's).
> 
> GOP with dynamic patching is certainly tricky-- I find it way too
> complicated to be generally useful.  However, Pd-l2ork should work without
> bugs with
> GOPs.  Things get fixed there, and bug reports don't sit around for ten
> years.
> 
> As far as connect messages-- I have exposed the canvas "find" method 
> inside
> an object called [canvasinfo] in pd-l2ork.  It would be possible to write
> a set of abstractions to faciliate connections using object/abstraction
> names instead of indices.  But like GOP, dynamic patching is at its core
> pretty
> clunky so it would still be difficult to dynamically patch things
> (especially doing it live).
> 
> > * Support for lists is quite limited. Wanna create a multidimentional
> array? Build your own. Want a hash map? Build your own. Luckily there's
> list-abs but it's weird that such basic functionality (that's present in
> most programming languages) is not a core language feature.
> 
> Data structures have support for multi-dimensional arrays.  In Pd-l2ork 
> you
> can create a scalar in an object box which makes it slightly easier to
> use them.  But it's definitely more complex than using list-abs or the
> newer array objects for single-dimensional arrays.
> 
> > * Sends and receives are global which creates a potential for conflicts.
> $0 can be used to avoid that but it looks ugly and many libraries, 
> patches,
> and I think even help files, don't use it.
> 
> I agree that $0 is ugly.  I've got some locality using data structures 
> with
> a "canvas" field in upcoming Pd-l2ork release, but it's still very
> experimental.
> 
> Pd-l2ork has [preset_hub] and [preset_node] which handle locality without
> $0.  It works quite well, but it would be an _enormous_ undertaking to
> use that-- or any other design-- as a general replacement for wireless
> 
> > * Help files are *.pd which sounds neat at first, until you realize that
> they're not easily searchable and can't be viewed online.
> 
> They are searchable in Pd-l2ork, as well as the last version of 
> 

Re: [PD] How's Pd limited?

[Eugene Lazarchik]

I consider sends and receives evil. They're similar to global variables or
goto statements in general purpose programming languages.

When you see a receive object, it's not obvious where all corresponding
sends may be. As opposed to simply following where the cords go.

Also, consider a subpatch (or abstraction), with certain cords connected to
it. In a way the inlets and outlets describe how this object can be used:
it can receive certain messages through inlets and then send output to the
outlets. But if there's sends and receives inside, it becomes much harder
to track what the object may do.

In regards to the screenshot: it could be simplified by putting stuff into
subpatches. However, even when there's only a couple of objects on a
subpatch, the cords can still cross the objects if there's no way to
segment them. Typical reasons include long objects ([pd
$0-descriptive-name-of-the-subpatch], or [t a a a a a a a a] or [route this
and that], etc.). Also it's hard to avoid a mess without segmenting if
there's a lot of feedback connections (when A's output is connected to B
but also B's output is connected to A).

Also, moving functionality in a subpatch usually should only be done when
there's something common between the objects inside and they implement a
relatively siloed functionality. Otherwise it may be hard to understand
what the subpatch is doing and the reader will have to constantly switch
between the parent and the subpatch to understand how they work together.

On Mon, Feb 22, 2016 at 12:25 PM, Matt Barber  wrote:

> I've said this before, but I think there are very good reasons not to ever
> include segmented patch cords (although hideable patch cords would be even
> worse). These two features are responsible for some of the very worst
> patching habits in Max/MSP. Have you ever been called on to run someone's
> patch, and you need to tweak something for your specific audio setup or fix
> a bug or whatever, and when you open it you get something that looks like
> this (one of the first "max patch" results on google image search):
>
> http://www.letatoubleu.com/OLcomposer_files/image001.jpg
>
> If you can't bend the cords there's much less of a temptation to make
> these kinds of can-of-worms patches, and more of an incentive to use
> send/receive when you need to get a value into an inconvenient place.
> There's also an incentive to make things more modular, which is usually far
> easier to debug than a huge sprawling patch. So while I can see where
> they'd be very useful if used judiciously, as someone who often has to
> operate someone else's patches, I'm very hesitant.
>
>
> On Mon, Feb 22, 2016 at 3:05 PM, Jonathan Wilkes via Pd-list <
> pd-list@lists.iem.at> wrote:
>
>> Hi Eugene,
>> Great post!
>>
>> I help develop pd-l2ork, and it addresses some of the points below.  I
>> recently got it building on OSX with most of the pd-extended libraries.
>>
>> I'll reply to each point below...
>>
>> > On Monday, February 22, 2016 4:21 AM, Eugene Lazarchik <
>> evgenius.lazarc...@gmail.com> wrote:
>>
>>
>> > Where do I start?
>>
>> > * Dynamic patching is officially not supported and bug/feature requests
>> get ignored. I had to jump through a lot of hoops to use dynamic patching
>> with GOP but I discovered a bunch of weird issues with subpatches not
>> getting redrawn and connectors left hanging after object deletion. Had to
>> build ugly hacks/workarounds since nobody's gonna fix the issues in PD.
>> Sending loadbangs to dynamically created objects is a pain, as well as
>> trying to dynamically connect them to something (most examples of using the
>> "connect" message use hardcoded object ID's).
>>
>> GOP with dynamic patching is certainly tricky-- I find it way too
>> complicated to be generally useful.  However, Pd-l2ork should work without
>> bugs with
>> GOPs.  Things get fixed there, and bug reports don't sit around for ten
>> years.
>>
>> As far as connect messages-- I have exposed the canvas "find" method
>> inside an object called [canvasinfo] in pd-l2ork.  It would be possible to
>> write
>> a set of abstractions to faciliate connections using object/abstraction
>> names instead of indices.  But like GOP, dynamic patching is at its core
>> pretty
>> clunky so it would still be difficult to dynamically patch things
>> (especially doing it live).
>>
>> > * Support for lists is quite limited. Wanna create a multidimentional
>> array? Build your own. Want a hash map? Build your own. Luckily there's
>> list-abs but it's weird that such basic functionality (that's present in
>> most programming languages) is not a core language feature.
>>
>> Data structures have support for multi-dimensional arrays.  In Pd-l2ork
>> you can create a scalar in an object box which makes it slightly easier to
>> use them.  But it's definitely more complex than using list-abs or the
>> newer array objects for single-dimensional arrays.
>>
>> > * Sends and receives are global which