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?

[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 mes

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

[PD] Messed font files

[Alexandros Drymonitis]

This problem doesn't concern Pd only, but it started through Pd (well, I
started it) and it is related to Pd, so I'm posting it here.
I've recently dual booted my laptop with Debian Jessie XFCE and in general
all is working fine. While doing some stuff in Pd (that's 0.46.2 from the
Jessie repositories) I created a [text2d] and got this error message:
[text2d]: cannot find font-file
'/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans.ttf'

So I looked in /usr/share/fonts/truetype and saw there was a dejavu/
directory, which had some font files in it, including DejavuSans.ttf. Now,
not being very linux-savvy, I changed the name of the directory to
ttf-dejavu/. [text2d] worked fine, but ever since, when I open Pd, I get
this message:
WARNING: Font family 'DejaVu Sans Mono' not found, using default (Courier
10 Pitch)

I tried to rename the directory back to dejavu/, but now the corresponding
font file is a "broken symbolic link to ../dejavu/DejaVuSansMono.ttf"

Renaming the directory back to ttf-dejavu/ doesn't work for [text2d] either.
It's a bit annoying because Pd's font is now quite small, and even if I
include the -font-size-12 flag in the Startup flags, if I open an existing
patch, the font goes back to 10, and the letters are quite small. I now
realize that this wasn't a very smart thing to do, but I did it...
All this might make sense to people who know the Linux system well, but
that's not the case with me and I'm experimenting. So, anyone knows a
solution to this? It would be nice if I could solve both  problems, Pd not
finding DejavuSansMono.ttf and [text2d] not finding DejavuSans.ttf

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

Re: [PD] Introducing GemmaLib

[Christof Ressi]

Thanks for sharing, great work! I hope it gets the attention it deserves. 

Personally I'm interested in two things:
 
1) What language/framework did you use for the GUI part?
2) Did you create the fancy auto completion for Pd or is that an already 
existing plug-in (I once found a plug-in a some years ago but it was quite 
buggy)
 
Christof 

Gesendet: Dienstag, 23. Februar 2016 um 17:13 Uhr
Von: "Zack Lee" 
An: pd-list@lists.iem.at, pd-...@lists.iem.at, pd-annou...@lists.iem.at
Betreff: [PD] Introducing GemmaLib

Hi guys,

I'm Zack and I would like to share the release of GemmaLib with you. 
 
I've been working on GemmaLib for quite a while now and I'm happy to finally 
share it with you.

GemmaLib is a set of Pd abstractions that allows you to easily create 
high-quality musical apps that run on mobile devices through the Gemma app 
(currently available on iOS). Feel free to check out this YouTube video to 
learn more: https://www.youtube.com/watch?v=FvPFKOkDOfo
 
You can get GemmaLib via 
http://www.iceblinkdigital.com/developers/[http://www.iceblinkdigital.com/developers/]
 or via 
https://github.com/iceblinkdigital/GemmaLib-1.0.1[https://github.com/iceblinkdigital/GemmaLib-1.0.1]

I'm looking forward to hearing your feedback!
Zack
___ Pd-list@lists.iem.at mailing 
list UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list[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]

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] Introducing GemmaLib

[Zack Lee]

Thanks a lot Dan! I owe you so much for creating this since I used ofxPd
for creating the Gemma app.

All the best,
Zack

2016-02-23 18:11 GMT+01:00 Dan Wilcox :

> Congrats. Looks like a lot of work came together for this.
>
> 
> Dan Wilcox
> @danomatika 
> danomatika.com
> robotcowboy.com
>
> On Feb 23, 2016, at 9:14 AM, pd-list-requ...@lists.iem.at wrote:
>
> *From: *Zack Lee 
> *Subject: **[PD] Introducing GemmaLib*
> *Date: *February 23, 2016 at 9:13:37 AM MST
> *To: *pd-list@lists.iem.at, pd-...@lists.iem.at, pd-annou...@lists.iem.at
>
>
> Hi guys,
>
> I'm Zack and I would like to share the release of GemmaLib with you.
>
> I've been working on GemmaLib for quite a while now and I'm happy to
> finally share it with you.
>
> GemmaLib is a set of Pd abstractions that allows you to easily create
> high-quality musical apps that run on mobile devices through the Gemma app
> (currently available on iOS). Feel free to check out this YouTube video to
> learn more: https://www.youtube.com/watch?v=FvPFKOkDOfo
>
>
> You can get GemmaLib via http://www.iceblinkdigital.com/developers/ or
> via https://github.com/iceblinkdigital/GemmaLib-1.0.1
>
> I'm looking forward to hearing your feedback!
>
> Zack
>
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Introducing GemmaLib

[Zack Lee]

Thank you for your interest Christof.

Here are the answers to your questions.

1) GemmaLib uses ‘GEM’(Graphics Environment for Multimedia) to easily
design a graphical interface of an app on the desktop platform by taking
the advantage of its real-time programming environment and flexibility.

Since it’s currently not possible to use‘GEM’ on mobile platforms, the
abstractions that contain ‘GEM’ externals will be replaced by pure vanilla
abstractions which simply forward the drawing info (e.g shape, size, color)
to ‘openFrameworks’(ofxPd) when a patch runs on the mobile device through
the Gemma app.

2) Yes, I created the auto completion for Pd. It's an abstraction made with
dynamic patching and keyboard detection. As far as I've tested It shouldn't
be buggy at all. I hope you like it. :)

Best wishes,
Zack




2016-02-24 13:12 GMT+01:00 Christof Ressi :

> Thanks for sharing, great work! I hope it gets the attention it deserves.
>
> Personally I'm interested in two things:
>
> 1) What language/framework did you use for the GUI part?
> 2) Did you create the fancy auto completion for Pd or is that an already
> existing plug-in (I once found a plug-in a some years ago but it was quite
> buggy)
>
> Christof
>
> Gesendet: Dienstag, 23. Februar 2016 um 17:13 Uhr
> Von: "Zack Lee" 
> An: pd-list@lists.iem.at, pd-...@lists.iem.at, pd-annou...@lists.iem.at
> Betreff: [PD] Introducing GemmaLib
>
> Hi guys,
>
> I'm Zack and I would like to share the release of GemmaLib with you.
>
> I've been working on GemmaLib for quite a while now and I'm happy to
> finally share it with you.
>
> GemmaLib is a set of Pd abstractions that allows you to easily create
> high-quality musical apps that run on mobile devices through the Gemma app
> (currently available on iOS). Feel free to check out this YouTube video to
> learn more: https://www.youtube.com/watch?v=FvPFKOkDOfo
>
> You can get GemmaLib via
> http://www.iceblinkdigital.com/developers/[http://www.iceblinkdigital.com/developers/]
>  or
> via
> https://github.com/iceblinkdigital/GemmaLib-1.0.1[https://github.com/iceblinkdigital/GemmaLib-1.0.1]
>
> I'm looking forward to hearing your feedback!
> Zack
> ___ Pd-list@lists.iem.at
> mailing list UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list[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] Parallel Audio Processing (Was: How's Pd limited?)

[Christof Ressi]

Another possibility for at least some degree of parallel audio processing, I 
guess, is to use streaming objects + several instances of Pd.  I tried out 
[udpsend~] and [udpreceive~] (taken from the "net" library in Pd extended) and 
they seem to work reliably. Of course there is some latency envolved and it's 
no practical solution for our future 100 core machines :-p.

What are in your experience the best methods for sharing audio via different Pd 
instances?
And does anyone know the current status of "Audio over OSC"? I found this paper 
from 2010 http://iem.kug.ac.at/fileadmin/media/iem/projects/2010/jaeger.pdf 
 
Christof



> Gesendet: Mittwoch, 24. Februar 2016 um 11:12 Uhr
> Von: Jack 
> An: pd-list@lists.iem.at
> Betreff: Re: [PD] How's Pd limited?
>
> 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
>

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

Re: [PD] Introducing GemmaLib

[Christof Ressi]

Very nice. By the way, I managed to unlock "Installer.pd" and have a look 
inside ;-). Very inspiring.

Actually, when I saw the GUI, I aksed myself "Is it GEM? But you can't have GEM 
in a mobile app... Maybe it's OpenFrameworks?". Funny to hear it's actually 
both.
I started using OF some months ago and it's such a great library.

 
 

Gesendet: Mittwoch, 24. Februar 2016 um 14:47 Uhr
Von: "Zack Lee" 
An: "Christof Ressi" 
Cc: pd-list@lists.iem.at
Betreff: Re: [PD] Introducing GemmaLib

Thank you for your interest Christof.
 
Here are the answers to your questions.
 
1) GemmaLib uses ‘GEM’(Graphics Environment for Multimedia) to easily design a 
graphical interface of an app on the desktop platform by taking the advantage 
of its real-time programming environment and flexibility.
 
Since it’s currently not possible to use‘GEM’ on mobile platforms, the 
abstractions that contain ‘GEM’ externals will be replaced by pure vanilla 
abstractions which simply forward the drawing info (e.g shape, size, color) to 
‘openFrameworks’(ofxPd) when a patch runs on the mobile device through the 
Gemma app.
 
2) Yes, I created the auto completion for Pd. It's an abstraction made with 
dynamic patching and keyboard detection. As far as I've tested It shouldn't be 
buggy at all. I hope you like it. :)
 
Best wishes,
Zack
 
 
 
 
2016-02-24 13:12 GMT+01:00 Christof Ressi :Thanks for 
sharing, great work! I hope it gets the attention it deserves.

Personally I'm interested in two things:

1) What language/framework did you use for the GUI part?
2) Did you create the fancy auto completion for Pd or is that an already 
existing plug-in (I once found a plug-in a some years ago but it was quite 
buggy)
 
Christof 

Gesendet: Dienstag, 23. Februar 2016 um 17:13 Uhr
Von: "Zack Lee" 
An: pd-list@lists.iem.at[pd-list@lists.iem.at], 
pd-...@lists.iem.at[pd-...@lists.iem.at], 
pd-annou...@lists.iem.at[pd-annou...@lists.iem.at]
Betreff: [PD] Introducing GemmaLib

Hi guys,

I'm Zack and I would like to share the release of GemmaLib with you. 
 
I've been working on GemmaLib for quite a while now and I'm happy to finally 
share it with you.

GemmaLib is a set of Pd abstractions that allows you to easily create 
high-quality musical apps that run on mobile devices through the Gemma app 
(currently available on iOS). Feel free to check out this YouTube video to 
learn more: 
https://www.youtube.com/watch?v=FvPFKOkDOfo[https://www.youtube.com/watch?v=FvPFKOkDOfo]
 
You can get GemmaLib via 
http://www.iceblinkdigital.com/developers/[http://www.iceblinkdigital.com/developers/][http://www.iceblinkdigital.com/developers/[http://www.iceblinkdigital.com/developers/]]
 or via 
https://github.com/iceblinkdigital/GemmaLib-1.0.1[https://github.com/iceblinkdigital/GemmaLib-1.0.1][https://github.com/iceblinkdigital/GemmaLib-1.0.1[https://github.com/iceblinkdigital/GemmaLib-1.0.1]]

I'm looking forward to hearing your feedback!
Zack
___ 
Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and 
account-management -> 
http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list][http://lists.puredata.info/listinfo/pd-list[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] Introducing GemmaLib

[Dan Wilcox]

It’s … it’s not a tcl-plugin? O.o


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 
> On Feb 24, 2016, at 6:48 AM, pd-list-requ...@lists.iem.at wrote:
> 
> 2) Yes, I created the auto completion for Pd. It's an abstraction made with 
> dynamic patching and keyboard detection. As far as I've tested It shouldn't 
> be buggy at all. I hope you like it. :)

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

Re: [PD] Introducing GemmaLib

[Joe White]

Yeah that's pretty insane Zack...

On 24 February 2016 at 15:58, Dan Wilcox  wrote:

> It’s … it’s not a tcl-plugin? O.o
>
> 
> Dan Wilcox
> @danomatika 
> danomatika.com
> robotcowboy.com
>
> On Feb 24, 2016, at 6:48 AM, pd-list-requ...@lists.iem.at wrote:
>
> 2) Yes, I created the auto completion for Pd. It's an abstraction made
> with dynamic patching and keyboard detection. As far as I've tested It
> shouldn't be buggy at all. I hope you like it. :)
>
>
>
> ___
> 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] Messed font files

[Dan Wilcox]

Sounds like the font files themselves in that folder were system links 
  so the fonts actually live 
elsewhere. In general, you do *not* want to change the folder structure outside 
of your /usr/home/USERNAME folder since the package management & OS rely on it.

I’d start by fining which package installs the font and creates the symlinks 
and then force install it. For Debian-based distros, I often use the Ubuntu 
package search to see which package contains the files I’m looking for. In this 
case, it looks like “font-dejavu-core”: 
http://packages.ubuntu.com/wily/all/fonts-dejavu-core/filelist 


If the font is back, then the issues related to GEM looking in the wrong path 
could be fixed via IOHannes or some GEM dev updating/making a new font search 
path to GEM. In the meantime, you can do a quick and dirty fix by making a 
symlink from the new font dir to the one GEM is looking for:

sudo ln -s  /usr/share/fonts/truetype/dejavu/ 
/usr/share/fonts/truetype/ttf-dejavu/

This way you will have both folders & one of them is just a link to the other.


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 
> On Feb 24, 2016, at 4:00 AM, pd-list-requ...@lists.iem.at wrote:
> 
> From: Alexandros Drymonitis mailto:adr...@gmail.com>>
> Subject: [PD] Messed font files
> Date: February 24, 2016 at 3:14:36 AM MST
> To: "pd-list@lists.iem.at " 
> mailto:pd-list@lists.iem.at>>
> 
> 
> This problem doesn't concern Pd only, but it started through Pd (well, I 
> started it) and it is related to Pd, so I'm posting it here.
> I've recently dual booted my laptop with Debian Jessie XFCE and in general 
> all is working fine. While doing some stuff in Pd (that's 0.46.2 from the 
> Jessie repositories) I created a [text2d] and got this error message:
> [text2d]: cannot find font-file 
> '/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans.ttf'
> 
> So I looked in /usr/share/fonts/truetype and saw there was a dejavu/ 
> directory, which had some font files in it, including DejavuSans.ttf. Now, 
> not being very linux-savvy, I changed the name of the directory to 
> ttf-dejavu/. [text2d] worked fine, but ever since, when I open Pd, I get this 
> message:
> WARNING: Font family 'DejaVu Sans Mono' not found, using default (Courier 10 
> Pitch)
> 
> I tried to rename the directory back to dejavu/, but now the corresponding 
> font file is a "broken symbolic link to ../dejavu/DejaVuSansMono.ttf"
> 
> Renaming the directory back to ttf-dejavu/ doesn't work for [text2d] either.
> It's a bit annoying because Pd's font is now quite small, and even if I 
> include the -font-size-12 flag in the Startup flags, if I open an existing 
> patch, the font goes back to 10, and the letters are quite small. I now 
> realize that this wasn't a very smart thing to do, but I did it...
> All this might make sense to people who know the Linux system well, but 
> that's not the case with me and I'm experimenting. So, anyone knows a 
> solution to this? It would be nice if I could solve both  problems, Pd not 
> finding DejavuSansMono.ttf and [text2d] not finding DejavuSans.ttf
> 
> Thanks

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

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?

[david medine]

Yeah, but the problem here (automatic compute resource distribution) 
isn't just with the actual distribution. Control timing is a huge issue 
too. If you have multiple voices of the same synth on different threads, 
good luck playing a chord. It will frequently be an arpeggio. If there 
are very strict, predictable rules about the order of when each voice 
computes and when it sleeps in order to wait for new samples and control 
signals, this problem vanishes, but then you are no longer computing in 
parallel, and you might as well have everything on one thread anyway.


This is a /really/ interesting problem. If someone can solve it, she 
deserves the nobel prize in computer music.


On 2/24/16 5:11 AM, martin brinkmann wrote:

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


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

Re: [PD] Parallel Audio Processing (Was: How's Pd limited?)

[david medine]

Reading a full inbox in a non-parallelized fashion leads to cross 
posting. Sorry for the repost, but this belongs on this thread.


Yeah, but the problem here (automatic compute resource distribution) 
isn't just with the actual distribution. Control timing is a huge issue 
too. If you have multiple voices of the same synth on different threads, 
good luck playing a chord. It will frequently be an arpeggio. If there 
are very strict, predictable rules about the order of when each voice 
computes and when it sleeps in order to wait for new samples and control 
signals, this problem vanishes, but then you are no longer computing in 
parallel, and you might as well have everything on one thread anyway.


This is a /really/ interesting problem. If someone can solve it, she 
deserves the nobel prize in computer music.


On 2/24/16 5:59 AM, Christof Ressi wrote:

Another possibility for at least some degree of parallel audio processing, I guess, is to 
use streaming objects + several instances of Pd.  I tried out [udpsend~] and 
[udpreceive~] (taken from the "net" library in Pd extended) and they seem to 
work reliably. Of course there is some latency envolved and it's no practical solution 
for our future 100 core machines :-p.

What are in your experience the best methods for sharing audio via different Pd 
instances?
And does anyone know the current status of "Audio over OSC"? I found this paper 
from 2010 http://iem.kug.ac.at/fileadmin/media/iem/projects/2010/jaeger.pdf
  
Christof





Gesendet: Mittwoch, 24. Februar 2016 um 11:12 Uhr
Von: Jack 
An: pd-list@lists.iem.at
Betreff: Re: [PD] How's Pd limited?

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 mailto:dmed...@ucsd.edu>> 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


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


___
Pd-list@lists.iem.at mailin

Re: [PD] Introducing GemmaLib

[Zack Lee]

Thanks guys, I'm glad you like it :)


2016-02-24 17:07 GMT+01:00 Joe White :

> Yeah that's pretty insane Zack...
>
> On 24 February 2016 at 15:58, Dan Wilcox  wrote:
>
>> It’s … it’s not a tcl-plugin? O.o
>>
>> 
>> Dan Wilcox
>> @danomatika 
>> danomatika.com
>> robotcowboy.com
>>
>> On Feb 24, 2016, at 6:48 AM, pd-list-requ...@lists.iem.at wrote:
>>
>> 2) Yes, I created the auto completion for Pd. It's an abstraction made
>> with dynamic patching and keyboard detection. As far as I've tested It
>> shouldn't be buggy at all. I hope you like it. :)
>>
>>
>>
>> ___
>> 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] Introducing GemmaLib

[Zack Lee]

Nice Christof :) And thanks again! Glad you like the installer.

Yeah, openFrameworks is great indeed :)



2016-02-24 15:29 GMT+01:00 Christof Ressi :

> Very nice. By the way, I managed to unlock "Installer.pd" and have a look
> inside ;-). Very inspiring.
>
> Actually, when I saw the GUI, I aksed myself "Is it GEM? But you can't
> have GEM in a mobile app... Maybe it's OpenFrameworks?". Funny to hear it's
> actually both.
> I started using OF some months ago and it's such a great library.
>
>
>
>
> Gesendet: Mittwoch, 24. Februar 2016 um 14:47 Uhr
> Von: "Zack Lee" 
> An: "Christof Ressi" 
> Cc: pd-list@lists.iem.at
> Betreff: Re: [PD] Introducing GemmaLib
>
> Thank you for your interest Christof.
>
> Here are the answers to your questions.
>
> 1) GemmaLib uses ‘GEM’(Graphics Environment for Multimedia) to easily
> design a graphical interface of an app on the desktop platform by taking
> the advantage of its real-time programming environment and flexibility.
>
> Since it’s currently not possible to use‘GEM’ on mobile platforms, the
> abstractions that contain ‘GEM’ externals will be replaced by pure vanilla
> abstractions which simply forward the drawing info (e.g shape, size, color)
> to ‘openFrameworks’(ofxPd) when a patch runs on the mobile device through
> the Gemma app.
>
> 2) Yes, I created the auto completion for Pd. It's an abstraction made
> with dynamic patching and keyboard detection. As far as I've tested It
> shouldn't be buggy at all. I hope you like it. :)
>
> Best wishes,
> Zack
>
>
>
>
> 2016-02-24 13:12 GMT+01:00 Christof Ressi :Thanks
> for sharing, great work! I hope it gets the attention it deserves.
>
> Personally I'm interested in two things:
>
> 1) What language/framework did you use for the GUI part?
> 2) Did you create the fancy auto completion for Pd or is that an already
> existing plug-in (I once found a plug-in a some years ago but it was quite
> buggy)
>
> Christof
>
> Gesendet: Dienstag, 23. Februar 2016 um 17:13 Uhr
> Von: "Zack Lee" 
> An: pd-list@lists.iem.at[pd-list@lists.iem.at], pd-...@lists.iem.at[
> pd-...@lists.iem.at], pd-annou...@lists.iem.at[pd-annou...@lists.iem.at]
> Betreff: [PD] Introducing GemmaLib
>
> Hi guys,
>
> I'm Zack and I would like to share the release of GemmaLib with you.
>
> I've been working on GemmaLib for quite a while now and I'm happy to
> finally share it with you.
>
> GemmaLib is a set of Pd abstractions that allows you to easily create
> high-quality musical apps that run on mobile devices through the Gemma app
> (currently available on iOS). Feel free to check out this YouTube video to
> learn more:
> https://www.youtube.com/watch?v=FvPFKOkDOfo[https://www.youtube.com/watch?v=FvPFKOkDOfo]
>
> You can get GemmaLib via
> http://www.iceblinkdigital.com/developers/[http://www.iceblinkdigital.com/developers/][http://www.iceblinkdigital.com/developers/[http://www.iceblinkdigital.com/developers/]]
>  or
> via
> https://github.com/iceblinkdigital/GemmaLib-1.0.1[https://github.com/iceblinkdigital/GemmaLib-1.0.1][https://github.com/iceblinkdigital/GemmaLib-1.0.1[https://github.com/iceblinkdigital/GemmaLib-1.0.1]]
>
> I'm looking forward to hearing your feedback!
> Zack
> ___ Pd-list@lists.iem.at[
> Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list[http://lists.puredata.info/listinfo/pd-list][http://lists.puredata.info/listinfo/pd-list[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

[PD] some notes for cyclone devs / maintainers

[katja]

Independent from the question who will contribute to cyclone in the
future and whose repository will be considered upstream I'd like to
share a few practical remarks on the build systems. In the old days I
would have sent this to pd-dev list but that may not be seen by
everyone involved now. A conversation can be redirected later.

Just like a library of books is more than a shelf with someone's
favorites, cyclone is more than a collection of Pd classes. For the
user it serves as a bridge between Pd and MaxMSP, but under the hood
it has consistency too, in the form of a specific framework. Pd users
don't need to know about hammer, sickle etc. as an interface to Pd,
but cyclone maintainers can't ignore it.

When Fred Jan started fixing bugs in cyclone, the code was embedded in
the programming structure of miXed, together with other libraries and
the shared framework. I got involved a bit later, with the
self-imposed task to develop a generalized build method for Pd
libraries that could support a complex source tree layout like
cyclone's. Since other libraries in miXed were essentially
unmaintained, with the exception of pddp which was forked inside
Pd-X's source tree earlier, I figured that cyclone's chances for
future maintenance would be best if it could be compiled with a build
system not relying on Pd-X or miXed as a set of libraries.

Cyclone's build system had over the years grown into an impenetrable
web of makefiles in miXed and Pd-X's library root dir. In the time
when Krzysztof Czaja started miXed, gnu make wasn't so '''advanced'''
as nowadays and he used some nifty tricks to design an expandable
build system, which in the end wasn't so expandable because no one
else could understand the tricks.

Today we have slightly more options for meta programming in gnu make,
notably the 'eval' function. The newly developed build method for
cyclone uses Makefile.pdlibbuilder, a generalized helper makefile for
Pd libraries big or small. Of course this helper makefile uses nifty
tricks too which aren't understood by everyone. But the calling
library makefile is transparent. And easily expandable.

An early version of the new build method was committed to SVN. When
IOhannes facilitated decentralization of Pd-extended with svn>git
conversion for all libraries, Fred Jan took cyclone to github for
continued maintenance. Technically speaking it is a fork, and
effectively it got split off from miXed. We've been considerate with
the structure and underlying framework though, conserving as many
pieces of the puzzle as could be put  together. Fred Jan reanimated a
part of cyclone that was lost to oblivion for a some years (nettles).
The makefile gives insight how class files per category relate to
dependencies in hammer, sickle etc.

Of course it is technically possible to add new classes which don't
use the framework functions. There are suggestions to start a new
library for new classes which follow a different code structure.
Indeed a split between classes using the framework and classes not
using it could simplify development. You can have independent
repositories, test / release cycles, and support. Cloning MaxMSP is
ambitious enough to justify division into sub projects. However if the
outcome of the discussion is that all must go in one cyclone lib, you
could at least organize source tree and build system in such a way
that dependencies between categories of classes and underlying
framework remain transparent. The build system could be split
according to categories of classes so devs can work in relative
isolation inbetween releases.

I'm not planning to participate in cyclone development myself, since
Makefile.pdlibbuilder is a big enough project for me to maintain,
apart from my personal Pd work. It is now unknown if cyclone will be
maintained as an individual library in its own repository or in a
larger context like Pd-L2Ork where it is still embedded in miXed. In
any case, here's my recommendation: make use of the new build
approach, because dealing with the old kludge of build scripts in
miXed won't make you happy in the long run.

Katja

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

Re: [PD] Messed font files

[Alexandros Drymonitis]

On Wed, Feb 24, 2016 at 6:11 PM, Dan Wilcox  wrote:

> Sounds like the font files themselves in that folder were system links
>   so the fonts actually live
> elsewhere. In general, you do *not* want to change the folder structure
> outside of your /usr/home/USERNAME folder since the package management & OS
> rely on it.
>
Well, now I know...

>
> I’d start by fining which package installs the font and creates the
> symlinks and then force install it. For Debian-based distros, I often use
> the Ubuntu package search to see which package contains the files I’m
> looking for. In this case, it looks like “font-dejavu-core”:
> http://packages.ubuntu.com/wily/all/fonts-dejavu-core/filelist
>
I don't quite get this, can you elaborate? If I type "locate
fonts-dejavu-core" I get this:
/usr/share/doc/fonts-dejavu-core
/usr/share/doc/fonts-dejavu-core/AUTHORS
/usr/share/doc/fonts-dejavu-core/BUGS
/usr/share/doc/fonts-dejavu-core/README
/usr/share/doc/fonts-dejavu-core/changelog.Debian.gz
/usr/share/doc/fonts-dejavu-core/changelog.gz
/usr/share/doc/fonts-dejavu-core/copyright
/usr/share/doc/fonts-dejavu-core/langcover.txt.gz
/usr/share/doc/fonts-dejavu-core/status.txt.gz
/usr/share/doc/fonts-dejavu-core/unicover.txt.gz
/var/lib/dpkg/info/fonts-dejavu-core.conffiles
/var/lib/dpkg/info/fonts-dejavu-core.list
/var/lib/dpkg/info/fonts-dejavu-core.md5sums

>
> If the font is back, then the issues related to GEM looking in the wrong
> path could be fixed via IOHannes or some GEM dev updating/making a new font
> search path to GEM. In the meantime, you can do a quick and dirty fix by
> making a symlink from the new font dir to the one GEM is looking for:
>
> sudo ln -s  /usr/share/fonts/truetype/dejavu/
> /usr/share/fonts/truetype/ttf-dejavu/
>
Yes, I thought about making a symbolic link after I wrote the previous
email (and obviously after I stupidly changed the name of the dejavu
directory). But if I create this dejavu directory and create a symbolic
link in it (afterwards I will create the ttf-dejavu, but now I'm also
missing dejavu), which file should the symbolic link point to? Typing
"locate dejavu-sans-mono" outputs this:
/etc/fonts/conf.avail/20-unhint-small-dejavu-sans-mono.conf
/etc/fonts/conf.avail/57-dejavu-sans-mono.conf
/etc/fonts/conf.d/20-unhint-small-dejavu-sans-mono.conf
/etc/fonts/conf.d/57-dejavu-sans-mono.conf

Is any of these files the one I need? This thread is quite off-topic, but
maybe not 100%...
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Messed font files

[Dan Wilcox]

That’s why I suggested reinstalling the package that installs the fonts & 
creates the symlink. If you force reinstall it, the symlinks should be 
recreated so things are back to where tou started. *Then* you can make the 
symlink to the missing folder.

Also, by “search for the package that contains the font”, I meant search 
*online* using the Ubuntu package search (my method at least), not on your 
local computer. My search turned up the package named: "fonts-dejavu-core”.

Since you’re on Debian, then you can do something like 
:

sudo apt —reinstall fonts-dejavu-core


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 
> On Feb 24, 2016, at 10:51 AM, Alexandros Drymonitis  wrote:
> 
>  But if I create this dejavu directory and create a symbolic link in it 
> (afterwards I will create the ttf-dejavu, but now I'm also missing dejavu), 
> which file should the symbolic link point to?

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

Re: [PD] Messed font files

[Alexandros Drymonitis]

On Wed, Feb 24, 2016 at 7:54 PM, Dan Wilcox  wrote:

> That’s why I suggested reinstalling the package that installs the fonts &
> creates the symlink. If you force reinstall it, the symlinks should be
> recreated so things are back to where tou started. *Then* you can make the
> symlink to the missing folder.
>
> Also, by “search for the package that contains the font”, I meant search
> *online* using the Ubuntu package search (my method at least), not on your
> local computer. My search turned up the package named: "fonts-dejavu-core”.
>
> Since you’re on Debian, then you can do something like
> 
> :
>
> sudo apt —reinstall fonts-dejavu-core
>
That worked! Actually the command was "sudo apt-get install --reinstall
fonts-dejavu-core". Now both Pd and [text2d] find their fonts, thanks!
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] some notes for cyclone devs / maintainers

[Alexandre Torres Porres]

2016-02-24 14:17 GMT-03:00 katja :

> the code was embedded in the programming structure of miXed, together with
> other libraries and the shared framework (...) Since other libraries in
> miXed were essentially unmaintained (...) I figured that cyclone's chances
> for future maintenance would be best if it could be compiled with a
> build system not relying on Pd-X or miXed as a set of libraries.
>

Makes sense to me.

Well, first, thanks for all the detailed information on how cyclone grew
into a giant kludge and current issues Katjia. So, It was brought to github
conserving as many pieces of the original puzzle as possible. But well,
yeah, seems like depending on old ways and days might be counterproductive
on the long run as you mentioned.  and it kinda relates to what Miller and
others were telling about how cyclone should maybe be left alone as it was
attached to "old ways of doing things", a new rebuild might be a good idea,
though quite ambitious.


> Of course it is technically possible to add new classes which don't
> use the framework functions (...) You can have independent repositories,
> test / release cycles, and support (...) if the outcome of the discussion
> is that all must go in one cyclone lib, you could at least organize source
> tree and build system in such a way that dependencies between categories of
> classes and underlying framework remain transparent. The build system could
> be split according to categories of classes so devs can work in relative
> isolation in between releases.


For now, I'm revising all the documentation and painstakingly correcting it
and testing objects looking for current issues. I've covered one third of
the audio objects to this moment (26), only 8 have no remarks. This is a
very time consuming task. I might take a month to recheck all current state
of objects.

I can propose a new beta release with minor bug fixes right away just for a
test, keeping things basically the way they already were. There's time to
think about everything else when this new report of the current state is
complete.

here's my recommendation: make use of the new build
> approach, because dealing with the old kludge of build scripts in
> miXed won't make you happy in the long run.
>

Agreed, thanks for the notes again.

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?

[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

[PD] -path subfolders ?...

[oliver]

hi, dear list !

a practical question:

is there a way to make pd look into subfolders of a given search path ?




thanks

oliver



--

/// http://pendler.klingt.org //
\\\ http://oliver.klingt.org  \\

 LIVE-BUILDER (music improvisation tool): \\
// http://tinyurl.com/qaohv35 //


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

Re: [PD] some notes for cyclone devs / maintainers

[katja]

On Wed, Feb 24, 2016 at 7:06 PM, Alexandre Torres Porres
 wrote:
> 2016-02-24 14:17 GMT-03:00 katja :
>>
>> the code was embedded in the programming structure of miXed, together with
>> other libraries and the shared framework (...) Since other libraries in
>> miXed were essentially unmaintained (...) I figured that cyclone's chances
>> for future maintenance would be best if it could be compiled with a build
>> system not relying on Pd-X or miXed as a set of libraries.
>
>
> Makes sense to me.
>
> Well, first, thanks for all the detailed information on how cyclone grew
> into a giant kludge and current issues Katjia. So, It was brought to github
> conserving as many pieces of the original puzzle as possible. But well,
> yeah, seems like depending on old ways and days might be counterproductive
> on the long run as you mentioned.  and it kinda relates to what Miller and
> others were telling about how cyclone should maybe be left alone as it was
> attached to "old ways of doing things", a new rebuild might be a good idea,
> though quite ambitious.

Alexandre, your summary of my notes about cyclone's build systems (old
and new) make a totally different story than I was telling. Cyclone
didn't grow into a kludge, only the build system did. That is now
solved as far as I am concerned.

For the rest: cyclone and it's underlying framework form a
well-structured but never completed body of code. I don't think anyone
suggested to rewrite it, if that is what you mean with 'rebuild'.
Rewriting is ambitious indeed, possibly beyond your imagination. And a
waste of time. Better focus on new functionality, and leave or
delegate maintenance of the existing code base to people who are able
and willing to understand it's structure.

Katja

>
>>
>> Of course it is technically possible to add new classes which don't
>> use the framework functions (...) You can have independent repositories,
>> test / release cycles, and support (...) if the outcome of the discussion is
>> that all must go in one cyclone lib, you could at least organize source tree
>> and build system in such a way that dependencies between categories of
>> classes and underlying framework remain transparent. The build system could
>> be split according to categories of classes so devs can work in relative
>> isolation in between releases.
>
>
> For now, I'm revising all the documentation and painstakingly correcting it
> and testing objects looking for current issues. I've covered one third of
> the audio objects to this moment (26), only 8 have no remarks. This is a
> very time consuming task. I might take a month to recheck all current state
> of objects.
>
> I can propose a new beta release with minor bug fixes right away just for a
> test, keeping things basically the way they already were. There's time to
> think about everything else when this new report of the current state is
> complete.
>
>> here's my recommendation: make use of the new build
>> approach, because dealing with the old kludge of build scripts in
>> miXed won't make you happy in the long run.
>
>
> Agreed, thanks for the notes again.
>
> 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?

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

Re: [PD] some notes for cyclone devs / maintainers

[Samuel Burt]

I just wanted to take a moment to thank the past, present, and future
developers of cyclone (and all the other great libraries I use). I tried
out MaxMSP back around 2000 and was lucky to find a collaborator who was
working with Pure Data. I have never really tried to make compatible
patches between the two and rarely worked with Max since. However, I have
used cyclone quite frequently because some of the objects have been
crucially important to my work over the years. (svf~ ftw!)

Whatever the future of cyclone is, your work has been and will be important.
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

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



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




___
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]

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

Re: [PD] Parallel Audio Processing (Was: How's Pd limited?)

[Jonathan Wilkes via Pd-list]

I'd say a solution would deserve the nobel prize in computers. :)

-Jonathan


On Wednesday, February 24, 2016 11:40 AM, david medine  
wrote:
 

  Reading a full inbox in a non-parallelized fashion leads to cross posting. 
Sorry for the repost, but this belongs on this thread.
 
 Yeah, but the problem here (automatic compute resource distribution) isn't 
just with the actual distribution. Control timing is a huge issue too. If you 
have multiple voices of the same synth on different threads, good luck playing 
a chord. It will frequently be an arpeggio. If there are very strict, 
predictable rules about the order of when each voice computes and when it 
sleeps in order to wait for new samples and control signals, this problem 
vanishes, but then you are no longer  computing in parallel, and you might as 
well have everything on one thread anyway. 
 
 This is a really interesting problem. If someone can solve it, she deserves 
the nobel prize in computer music.
 
 On 2/24/16 5:59 AM, Christof Ressi wrote:
  
 Another possibility for at least some degree of parallel audio processing, I 
guess, is to use streaming objects + several instances of Pd.  I tried out 
[udpsend~] and [udpreceive~] (taken from the "net" library in Pd extended) and 
they seem to work reliably. Of course there is some latency envolved and it's 
no practical solution for our future 100 core machines :-p.

What are in your experience the best methods for sharing audio via different Pd 
instances?
And does anyone know the current status of "Audio over OSC"? I found this paper 
from 2010 http://iem.kug.ac.at/fileadmin/media/iem/projects/2010/jaeger.pdf 
 
Christof



 
 Gesendet: Mittwoch, 24. Februar 2016 um 11:12 Uhr
Von: Jack 
An: pd-list@lists.iem.at
Betreff: Re: [PD] How's Pd limited?

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 mailto:dmed...@ucsd.edu>> 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

 
 ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and accoun

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 
mailto: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 mailto: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
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 four

Re: [PD] Parallel Audio Processing (Was: How's Pd limited?)

[David Medine]

That is definitely true. Of course, we musicians need it more than most 
computer users out there...


On 2/24/2016 11:57 AM, Jonathan Wilkes wrote:

I'd say a solution would deserve the nobel prize in computers. :)

-Jonathan


On Wednesday, February 24, 2016 11:40 AM, david medine 
 wrote:



Reading a full inbox in a non-parallelized fashion leads to cross 
posting. Sorry for the repost, but this belongs on this thread.


Yeah, but the problem here (automatic compute resource distribution) 
isn't just with the actual distribution. Control timing is a huge 
issue too. If you have multiple voices of the same synth on different 
threads, good luck playing a chord. It will frequently be an arpeggio. 
If there are very strict, predictable rules about the order of when 
each voice computes and when it sleeps in order to wait for new 
samples and control signals, this problem vanishes, but then you are 
no longer computing in parallel, and you might as well have everything 
on one thread anyway.


This is a /really/ interesting problem. If someone can solve it, she 
deserves the nobel prize in computer music.


On 2/24/16 5:59 AM, Christof Ressi wrote:

Another possibility for at least some degree of parallel audio processing, I guess, is to 
use streaming objects + several instances of Pd.  I tried out [udpsend~] and 
[udpreceive~] (taken from the "net" library in Pd extended) and they seem to 
work reliably. Of course there is some latency envolved and it's no practical solution 
for our future 100 core machines :-p.

What are in your experience the best methods for sharing audio via different Pd 
instances?
And does anyone know the current status of "Audio over OSC"? I found this paper from 2010http://iem.kug.ac.at/fileadmin/media/iem/projects/2010/jaeger.pdf  
  
Christof





Gesendet: Mittwoch, 24. Februar 2016 um 11:12 Uhr
Von: Jack 
An:pd-list@lists.iem.at 
Betreff: Re: [PD] How's Pd limited?

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 mailto:dmed...@ucsd.edu>
 > 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-

Re: [PD] Parallel Audio Processing (Was: How's Pd limited?)

[nicolas bouillot]

a possible source of inspiration: "supernova a scalable parallel audio
synthesis server for SuperCollider". It works great.
http://tim.klingt.org/publications/icmc2011_supernova.pdf

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

> That is definitely true. Of course, we musicians need it more than most
> computer users out there...
>
> On 2/24/2016 11:57 AM, Jonathan Wilkes wrote:
>
> I'd say a solution would deserve the nobel prize in computers. :)
>
> -Jonathan
>
>
> On Wednesday, February 24, 2016 11:40 AM, david medine 
>  wrote:
>
>
> Reading a full inbox in a non-parallelized fashion leads to cross posting.
> Sorry for the repost, but this belongs on this thread.
>
> Yeah, but the problem here (automatic compute resource distribution) isn't
> just with the actual distribution. Control timing is a huge issue too. If
> you have multiple voices of the same synth on different threads, good luck
> playing a chord. It will frequently be an arpeggio. If there are very
> strict, predictable rules about the order of when each voice computes and
> when it sleeps in order to wait for new samples and control signals, this
> problem vanishes, but then you are no longer computing in parallel, and you
> might as well have everything on one thread anyway.
>
> This is a *really* interesting problem. If someone can solve it, she
> deserves the nobel prize in computer music.
>
> On 2/24/16 5:59 AM, Christof Ressi wrote:
>
> Another possibility for at least some degree of parallel audio processing, I 
> guess, is to use streaming objects + several instances of Pd.  I tried out 
> [udpsend~] and [udpreceive~] (taken from the "net" library in Pd extended) 
> and they seem to work reliably. Of course there is some latency envolved and 
> it's no practical solution for our future 100 core machines :-p.
>
> What are in your experience the best methods for sharing audio via different 
> Pd instances?
> And does anyone know the current status of "Audio over OSC"? I found this 
> paper from 2010 
> http://iem.kug.ac.at/fileadmin/media/iem/projects/2010/jaeger.pdf
>
> Christof
>
>
>
>
> Gesendet: Mittwoch, 24. Februar 2016 um 11:12 Uhr
> Von: Jack  
> An: pd-list@lists.iem.at
> Betreff: Re: [PD] How's Pd limited?
>
> 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 
> mailto:dmed...@ucsd.edu> > 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 

Re: [PD] Messed font files

[IOhannes m zmölnig]

On 02/24/2016 07:06 PM, Alexandros Drymonitis wrote:
>> > Since you’re on Debian, then you can do something like
>> > 
>> > :
>> >
>> > sudo apt —reinstall fonts-dejavu-core
>> >
> That worked! Actually the command was "sudo apt-get install --reinstall
> fonts-dejavu-core". Now both Pd and [text2d] find their fonts, thanks!
> 

hmm, you are experiencing a bug in the "gem" package as shipped with Ubuntu.

please report a bug against the "gem" package (using the `reportbug`
cmdline tool), describing your problem.

gamrds
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] some notes for cyclone devs / maintainers

[Jonathan Wilkes via Pd-list]

Just to add a bit on why build complexity is important:I probably wasted 20% of 
my time building the GUI port on OSX due to the complexity of the flext build 
system.  
And apparently I am not the only one who views it as voodoo, because the 
externals/Makefile calls 
the flext "build.sh" one more time than the documentation says is necessary.  
(Which, btw, is officially a 
total of 3 calls.)

I say "waste" because I still don't have a working version of flext in the app 
bundle.  Of course if I can 
actually get it to work, I'll just leave it there and probably never touch it 
again like the rest of the Pd-extended 
build monstrosity. :)

So a simple build process is worth its weight in gold.  More than that, a 
non-standard build system is a good 
filter for keeping new code out of the ecosystem-- both because it's too 
tedious to use, and too complex for the 
community to maintain.  (Where non-standard is anything other than autotools or 
make with the usual 
targets.)

-Jonathan

On Wednesday, February 24, 2016 2:08 PM, katja  
wrote:
 

 On Wed, Feb 24, 2016 at 7:06 PM, Alexandre Torres Porres
 wrote:
> 2016-02-24 14:17 GMT-03:00 katja :
>>
>> the code was embedded in the programming structure of miXed, together with
>> other libraries and the shared framework (...) Since other libraries in
>> miXed were essentially unmaintained (...) I figured that cyclone's chances
>> for future maintenance would be best if it could be compiled with a build
>> system not relying on Pd-X or miXed as a set of libraries.
>
>
> Makes sense to me.
>
> Well, first, thanks for all the detailed information on how cyclone grew
> into a giant kludge and current issues Katjia. So, It was brought to github
> conserving as many pieces of the original puzzle as possible. But well,
> yeah, seems like depending on old ways and days might be counterproductive
> on the long run as you mentioned.  and it kinda relates to what Miller and
> others were telling about how cyclone should maybe be left alone as it was
> attached to "old ways of doing things", a new rebuild might be a good idea,
> though quite ambitious.

Alexandre, your summary of my notes about cyclone's build systems (old
and new) make a totally different story than I was telling. Cyclone
didn't grow into a kludge, only the build system did. That is now
solved as far as I am concerned.

For the rest: cyclone and it's underlying framework form a
well-structured but never completed body of code. I don't think anyone
suggested to rewrite it, if that is what you mean with 'rebuild'.
Rewriting is ambitious indeed, possibly beyond your imagination. And a
waste of time. Better focus on new functionality, and leave or
delegate maintenance of the existing code base to people who are able
and willing to understand it's structure.

Katja

>
>>
>> Of course it is technically possible to add new classes which don't
>> use the framework functions (...) You can have independent repositories,
>> test / release cycles, and support (...) if the outcome of the discussion is
>> that all must go in one cyclone lib, you could at least organize source tree
>> and build system in such a way that dependencies between categories of
>> classes and underlying framework remain transparent. The build system could
>> be split according to categories of classes so devs can work in relative
>> isolation in between releases.
>
>
> For now, I'm revising all the documentation and painstakingly correcting it
> and testing objects looking for current issues. I've covered one third of
> the audio objects to this moment (26), only 8 have no remarks. This is a
> very time consuming task. I might take a month to recheck all current state
> of objects.
>
> I can propose a new beta release with minor bug fixes right away just for a
> test, keeping things basically the way they already were. There's time to
> think about everything else when this new report of the current state is
> complete.
>
>> here's my recommendation: make use of the new build
>> approach, because dealing with the old kludge of build scripts in
>> miXed won't make you happy in the long run.
>
>
> Agreed, thanks for the notes again.
>
> 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] -path subfolders ?...

[Antoine Rousseau]

you can use [foo/bar] to call a patch file "bar.pd" located into a
directory named "foo" which is findable by search paths.

2016-02-24 19:50 GMT+01:00 oliver :

> hi, dear list !
>
> a practical question:
>
> is there a way to make pd look into subfolders of a given search path ?
>
>
>
>
> thanks
>
> oliver
>
>
>
> --
> 
> /// http://pendler.klingt.org //
> \\\ http://oliver.klingt.org  \\
> 
>  LIVE-BUILDER (music improvisation tool): \\
> // http://tinyurl.com/qaohv35 //
> 
>
> ___
> 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] Parallel Audio Processing (Was: How's Pd limited?)

[Jonathan Wilkes via Pd-list]

> a possible source of inspiration: "supernova a scalable parallel audio 
> synthesis server for SuperCollider". It works great.
He actually started with a Pd-like system called "Nova", and commented on the 
bug tracker awhile back about making Pd thread-safe.  
He also worked on a development branch of Pd-extended, but I don't see much 
documentation about how that ended up.

-Jonathan 

On Wednesday, February 24, 2016 3:06 PM, nicolas bouillot 
 wrote:
 

 a possible source of inspiration: "supernova a scalable parallel audio 
synthesis server for SuperCollider". It works great.
http://tim.klingt.org/publications/icmc2011_supernova.pdf
On Wed, Feb 24, 2016 at 2:58 PM, David Medine  wrote:

  That is definitely true. Of course, we musicians need it more than most 
computer users out there...
 
 On 2/24/2016 11:57 AM, Jonathan Wilkes wrote:
  
 I'd say a solution would deserve the nobel prize in computers. :)
 
  -Jonathan
  
 
  On Wednesday, February 24, 2016 11:40 AM, david medine  
wrote:
  
 
Reading a full inbox in a non-parallelized fashion leads to cross posting. 
Sorry for the repost, but this belongs on this thread.
 
 Yeah, but the problem here (automatic compute resource distribution) isn't 
just with the actual distribution. Control timing is a huge issue too. If you 
have multiple voices of the same synth on different threads, good luck playing 
a chord. It  will frequently be an arpeggio. If there are very strict, 
predictable rules about the order of when each voice computes and when it 
sleeps in order to wait for new samples and control signals, this problem 
vanishes, but then you are no longer  computing in parallel, and you might as 
well have everything on one thread anyway. 
 
 This is a really interesting problem. If someone can solve it, she deserves 
the nobel prize in computer music.
 
 On 2/24/16 5:59 AM, Christof Ressi wrote:

 Another possibility for at least some degree of parallel audio processing, I 
guess, is to use streaming objects + several instances of Pd.  I tried out 
[udpsend~] and [udpreceive~] (taken from the "net" library in Pd extended) and 
they seem to work reliably. Of course there is some latency envolved and it's 
no practical solution for our future 100 core machines :-p.

What are in your experience the best methods for sharing audio via different Pd 
instances?
And does anyone know the current status of "Audio over OSC"? I found this paper 
from 2010 http://iem.kug.ac.at/fileadmin/media/iem/projects/2010/jaeger.pdf 
 
Christof



 
 Gesendet: Mittwoch, 24. Februar 2016 um 11:12 Uhr
Von: Jack 
An: pd-list@lists.iem.at
Betreff: Re: [PD] How's Pd limited?

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 mailto:dmed...@ucsd.edu>> 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...

_

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 separate core?

 Sam





>>>

Re: [PD] Pd-list Digest, Vol 131, Issue 154

[Dan Wilcox]

That would be good info to have, especially now that there has been a growing 
discussion around pd supporting multiple instances for libpd VST/AudioUnit use. 
We have the prelim work that Miller has done in this area but there are still 
related issues.


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 
> On Feb 24, 2016, at 1:39 PM, pd-list-requ...@lists.iem.at wrote:
> 
> 
> From: Jonathan Wilkes mailto:jancs...@yahoo.com>>
> Subject: Re: [PD] Parallel Audio Processing (Was: How's Pd limited?)
> Date: February 24, 2016 at 1:39:01 PM MST
> To: nicolas bouillot  >, David Medine  >
> Cc: "pd-list@lists.iem.at " 
> mailto:pd-list@lists.iem.at>>
> Reply-To: Jonathan Wilkes mailto:jancs...@yahoo.com>>
> 
> 
> > a possible source of inspiration: "supernova a scalable parallel audio 
> > synthesis server for SuperCollider". It works great.
> 
> He actually started with a Pd-like system called "Nova", and commented on the 
> bug tracker awhile back about making Pd thread-safe.  
> He also worked on a development branch of Pd-extended, but I don't see much 
> documentation about how that ended up.
> 
> -Jonathan

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

Re: [PD] -path subfolders ?...

[oliver]

Antoine Rousseau wrote:

you can use [foo/bar] to call a patch file "bar.pd" located into a
directory named "foo" which is findable by search paths.



i'm aware of that. but what if there are 50 or more subfolders inside 
the main directory ?


what i was looking for, was a kind of "trick" that i could use to avoid 
having to know and type ALL possible subfolders of a searchpath in the 
PD startup script with the -path switch.


say, i have a series of abstractions or libraries that get dynamically 
loaded and i don't want to put them all into one folder, but into 
several subfolders that make organisation easier.


right now ia have to literally define any subfolder to make sure PD 
finds it. is there any workaround for that ? like special characters ?


thanks

oliver

___
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]

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 
> sound
> you want, this winds up creating a p

Re: [PD] some notes for cyclone devs / maintainers

[Alexandre Torres Porres]

I'm certainly not able to grasp the whole deal, maybe just get the gist of
it and certainly willing to. But I'm partnered with a colleague that I
believe is technically capable besides only willing. We'd need a lot of
"filling us in" though.

cheers

2016-02-24 16:05 GMT-03:00 katja :

> On Wed, Feb 24, 2016 at 7:06 PM, Alexandre Torres Porres
>  wrote:
> > 2016-02-24 14:17 GMT-03:00 katja :
> >>
> >> the code was embedded in the programming structure of miXed, together
> with
> >> other libraries and the shared framework (...) Since other libraries in
> >> miXed were essentially unmaintained (...) I figured that cyclone's
> chances
> >> for future maintenance would be best if it could be compiled with a
> build
> >> system not relying on Pd-X or miXed as a set of libraries.
> >
> >
> > Makes sense to me.
> >
> > Well, first, thanks for all the detailed information on how cyclone grew
> > into a giant kludge and current issues Katjia. So, It was brought to
> github
> > conserving as many pieces of the original puzzle as possible. But well,
> > yeah, seems like depending on old ways and days might be
> counterproductive
> > on the long run as you mentioned.  and it kinda relates to what Miller
> and
> > others were telling about how cyclone should maybe be left alone as it
> was
> > attached to "old ways of doing things", a new rebuild might be a good
> idea,
> > though quite ambitious.
>
> Alexandre, your summary of my notes about cyclone's build systems (old
> and new) make a totally different story than I was telling. Cyclone
> didn't grow into a kludge, only the build system did. That is now
> solved as far as I am concerned.
>
> For the rest: cyclone and it's underlying framework form a
> well-structured but never completed body of code. I don't think anyone
> suggested to rewrite it, if that is what you mean with 'rebuild'.
> Rewriting is ambitious indeed, possibly beyond your imagination. And a
> waste of time. Better focus on new functionality, and leave or
> delegate maintenance of the existing code base to people who are able
> and willing to understand it's structure.
>
> Katja
>
> >
> >>
> >> Of course it is technically possible to add new classes which don't
> >> use the framework functions (...) You can have independent repositories,
> >> test / release cycles, and support (...) if the outcome of the
> discussion is
> >> that all must go in one cyclone lib, you could at least organize source
> tree
> >> and build system in such a way that dependencies between categories of
> >> classes and underlying framework remain transparent. The build system
> could
> >> be split according to categories of classes so devs can work in relative
> >> isolation in between releases.
> >
> >
> > For now, I'm revising all the documentation and painstakingly correcting
> it
> > and testing objects looking for current issues. I've covered one third of
> > the audio objects to this moment (26), only 8 have no remarks. This is a
> > very time consuming task. I might take a month to recheck all current
> state
> > of objects.
> >
> > I can propose a new beta release with minor bug fixes right away just
> for a
> > test, keeping things basically the way they already were. There's time to
> > think about everything else when this new report of the current state is
> > complete.
> >
> >> here's my recommendation: make use of the new build
> >> approach, because dealing with the old kludge of build scripts in
> >> miXed won't make you happy in the long run.
> >
> >
> > Agreed, thanks for the notes again.
> >
> > 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?

[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 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 >
 
         One thing I'd be inte

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, tambourine, etc. Each would begin 
>> and
>> end at a zero crossing so you could

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] -path subfolders ?...

[Antoine Rousseau]

I don't think it's currently possible.
It could definitively be a feature request to allow the use of wildcards in
preferences paths, like "~/pd-externals/myLib/*"... But I would say it's
not trivial to implement to the code.

A workaround is to write a subpatch where you [declare -path] all your
subfolders, and copy this subpatch where needed. It currently also works if
you nest your list of [declare]s into an abstraction (which makes it easier
to copy in application patches), but I hope it will still be the case in
the future.


2016-02-24 22:46 GMT+01:00 oliver :

> Antoine Rousseau wrote:
>
>> you can use [foo/bar] to call a patch file "bar.pd" located into a
>> directory named "foo" which is findable by search paths.
>>
>>
> i'm aware of that. but what if there are 50 or more subfolders inside the
> main directory ?
>
> what i was looking for, was a kind of "trick" that i could use to avoid
> having to know and type ALL possible subfolders of a searchpath in the PD
> startup script with the -path switch.
>
> say, i have a series of abstractions or libraries that get dynamically
> loaded and i don't want to put them all into one folder, but into several
> subfolders that make organisation easier.
>
> right now ia have to literally define any subfolder to make sure PD finds
> it. is there any workaround for that ? like special characters ?
>
> thanks
>
> oliver
>
>
> ___
> 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] -path subfolders ?...

[oliver]

Antoine Rousseau wrote:

I don't think it's currently possible. It could definitively be a
feature request to allow the use of wildcards in preferences paths,
like "~/pd-externals/myLib/*"... But I would say it's not trivial to
implement to the code.

A workaround is to write a subpatch where you [declare -path] all
your subfolders, and copy this subpatch where needed. It currently
also works if you nest your list of [declare]s into an abstraction
(which makes it easier to copy in application patches), but I hope it
will still be the case in the future.



ok, thanks for clarification !

best

oliver

___
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 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 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 in

Re: [PD] Introducing GemmaLib

[oliver]

hi,

i was just curious and tried this great piece of work.
looks very promising !

unfortunately PD dies with no further explanation, when i try to open a 
GUI-related abstraction (the ones starting with p. or g.)


all other patches open and work alright (as far as i have tested)

i think i set all searchpaths right, and the GEM library is loaded 
anyway in my setup. any idea what could be wrong here ?


my system:
Windows 7, 64bit, PD vanilla 0.46.7

___
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 what (if
> anything)
> someone tried to do in Pd, but couldn't given its limitations
> (apart
> from l

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]

how about the "tanhauser" (heavy audio tools now) compiler, that can
compile patches to C code, and then, on another step on this chain, we
could make it an external?

looks like a window into a gen~ like idea, but I might be far off

cheers

2016-02-24 21:59 GMT-03:00 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 <
> ovaltinevor...@gmail.com> 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 < 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 

[PD] How's Max MSP limited? was Re: How's Pd limited?

[Samuel Burt]

Alexandre,

Since I haven't used Max in a very long time, maybe you can explain. What
are the surprising limitations you've discovered with Max MSP?

Sam


>
> --
>
> Message: 2
> Date: Wed, 24 Feb 2016 23:19:53 -0300
> From: Alexandre Torres Porres 
> To: peiman khosravi 
> Cc: cyrille henry , Pd-List 
> Subject: Re: [PD] How's Pd limited?
> Message-ID:
> <
> caeasfmgwznn+slsfwcf6nv+o761mgvmgzuhmvnfkqxqfcjk...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 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
>
> 
>
___
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]

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 Max MSP limited? was Re: How's Pd limited?

[Alexandre Torres Porres]

som objects that you'd bet they'd have, but they don't (maybe externals). I
could stop one day and list them all (I'm actually working on a table
comparing objects in Pd x Max & SC).

I know pd vanilla lacks too much of anything, but if you're using extended,
well, there's just a lot in it that max doesn't have. Actually, even some
vanilla features (like the lack of a method to generate a table made of a
sum of sines).

we were also talking about something like [vline~] in Pd vanilla, which is
powerful for sample accurate triggering, but Max doesn't have it.

Oh, pd has no control rate limitation at all, it's what allows vline~ to
achieve sub sample accuracy by the way. But Max's control rate is 2ms by
default and goes only down to 1ms...

I also miss our dear friend [bang~] in max, the workaround to that is too
ugly.

well, what other limitations? It doesn't run on linux or single board
computers under 10$ like raspberry pi 0 - libpd also takes Pd to weird
places, I foresse the day you might be able to run a pd patch in a toaster

Anyway, everything will have it's limitations. I bet there are tons of
things you can do in SC that you can't do in Max or Pd. But I was shocked
to learn you can't do any sub-block "subpatch" in SC without having to run
the whole beast globally into a block of "1" sample (it probably won't
allow it ever).

that's why I believe so much in investing on a project like cyclone - I
just miss some of those objects, and if I could just steal them - great! I
also fantasize about cloning and stealing SC's very nice set of objects and
bring them to Pd.

cheers

2016-02-25 0:20 GMT-03:00 Samuel Burt :

> Alexandre,
>
> Since I haven't used Max in a very long time, maybe you can explain. What
> are the surprising limitations you've discovered with Max MSP?
>
> Sam
>
>
>>
>> --
>>
>> Message: 2
>> Date: Wed, 24 Feb 2016 23:19:53 -0300
>> From: Alexandre Torres Porres 
>> To: peiman khosravi 
>> Cc: cyrille henry , Pd-List 
>> Subject: Re: [PD] How's Pd limited?
>> Message-ID:
>> <
>> caeasfmgwznn+slsfwcf6nv+o761mgvmgzuhmvnfkqxqfcjk...@mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> 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
>>
>> 
>>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list