Re: [PD] How's Pd limited?

[Brian Fay]

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

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

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

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

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

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


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

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

 cheers
 c


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

Re: [PD] How's Pd limited?

[Brian Fay]

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

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

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

Re: [PD] [Bulk] pd in a eurorack modular system

[Brian Fay]

I haven't taken great measurements of this stuff, but from what I can
remember, PD startup is very fast - I am using -nogui, it only takes a
second or two.

But booting up the OS takes a while. I'm sure you can optimize by turning
off unnecessary startup services, but I don't think you can get it down to
just a few seconds (again, I'd be very happy to be proven wrong).
On Apr 18, 2015 7:44 PM, Jonathan Wilkes via Pd-list pd-list@lists.iem.at
wrote:

 On 04/17/2015 02:39 PM, Brian Fay wrote:

 I think my Model B took closer to a minute to fully boot and start my Pd
 patch.

 The Model 2 seems a little faster, maybe 30 seconds or less, but
 unfortunately I don't think an almost instant boot time is realistic (I
 would LOVE to be proven wrong on this). It's definitely one of the more
 frustrating things, if you want to use the Pi at a gig or something. Then
 again, it could be a lot worse.


 Is the load time any different using the -nogui flag?

 Also, how many abstractions are there in your patch?

 -Jonathan

 ___
 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] [Bulk] pd in a eurorack modular system

[Brian Fay]

I think my Model B took closer to a minute to fully boot and start my Pd
patch.

The Model 2 seems a little faster, maybe 30 seconds or less, but
unfortunately I don't think an almost instant boot time is realistic (I
would LOVE to be proven wrong on this). It's definitely one of the more
frustrating things, if you want to use the Pi at a gig or something. Then
again, it could be a lot worse.


The determining factors will probably be what distro you're using, and how
many services have to be started up at the very beginning.

-Brian

On Fri, Apr 17, 2015 at 1:42 PM, Alessio Degani alessio.deg...@ymail.com
wrote:

 On 15/04/2015 11:28, Joe White wrote:

 Pretty much instant AFAIK

 Hi,

 I've asked that question to a friend of mine, that uses Raspberry PI,
 model A (I think...), and he told me that has a boot time of about 34
 seconds.

 It is different from model to model (i.e. model B, A+)?
 Or there are some trick (i.e. different OS, or whatelse...) to achieve an
 almost instant boot time?

 Thank you


 --
 a.


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

[Brian Fay]

Wow, that's unexpected! :(

Are other audio-related things working fine?

-Brian

On Fri, Feb 6, 2015 at 3:40 PM, katja katjavet...@gmail.com wrote:

 Hello,

 I got that new Raspberry Pi model 2b. It is indeed much faster than b
 or b+ in practice, but alarmingly, I can't get useful sound from Pd.
 Continuous dropouts, no matter if built-in output or USB sound card
 (iMic) is used. I've built puredata 0.46-2 from Raspbian jessie
 source, for sure it has real time prio (can verify when starting Pd
 with option -verbose). No clue what is going on here, so far.

 Katja

 On Thu, Feb 5, 2015 at 3:54 AM, Simon Wise simonzw...@gmail.com wrote:
  On 05/02/15 12:51, Simon Wise wrote:
 
  (I haven't checked out the newest Pi at all yet, it apparently has a
 very
  much
  more powerful processor so is quite a different beast)
 
 
  Ok ... so it is a very similar chip with Quad-core ARMv7 replacing the
  single core ARMv6, with the rest of the chip apparently left unchanged
 ...
  so same USB and same graphics, more CPU for audio and a desktop, still
 less
  than half the price of an Udoo.
 
  Not much docs up yet at all, but there are images for a few systems ...
 kind
  of typical.
 
  And the move to ARMv7 takes it closer to current hardware, so for example
  there isn't the same need to build raspbian as a half-way house between 2
  debian builds ... for now they say they are keeping the same user-space
 in
  both raspbian builds and seem to have compatibility high on their agenda.
 
  Has anyone here actually got one yet?
 
  Simon
 
 
  ___
  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] I2S audio possibilities

[Brian Fay]

Thanks for the info, my experience with USB was pretty similar - had to run
Pd in headless mode (no X), and definitely needed to do a lot of tweaking
before things were satisfying.

The Wolfson sounds like it could be a little bit of work to get running,
but I'm glad to hear that the quality is good. I'll keep an eye on it and
see if they do anything to support the new model of the Pi.

On Wed, Feb 4, 2015 at 11:58 AM, Simon Wise simonzw...@gmail.com wrote:

 On 05/02/15 02:34, Brian Fay wrote:

 Simon, have you compared the wolfson to any USB interfaces? I'm curious
 about how it performs by comparison, using no more than 2 input and 2
 output channels. I had some success with a USB interface on a Pi using pd
 and alsa, and got down to somewhere around 15 milliseconds of latency.

 I couldn't avoid occasional pops and clicks, and if I really pushed the
 number of effects I was using at once I would get some serious xruns. With
 the wolfson bypassing USB altogether, is it easier to achieve a low
 latency?


 I have found that you really need to minimise everything to get the Pis
 running smoothly, certainly no X and only what is strictly needed for
 control .. they are not powerful devices but the access you have to GPIOs
 and such, and the ability to program things at a low level means they can
 be made to do some tasks well, and fast. The usb is to be avoided if at all
 possible, I'd like to test the A model (with the single USB-OTG directly
 from the chip) it might be better than going via that usb/ethernet chip,
 the A+ looks really compact as well.

 I didn't need low latency, I got the wolfsons hoping for better quality
 analogue I/O, their digital I/O options, the possibility of linking them
 clock-wise and to avoid the endless usb hassles (there are other things I
 need the USB for!) ... they work well for this and I will do some serious
 testing but the audio has been clean and sounding good so far ... and I
 have learnt quite a lot about the various low level interface options.


 And since you mentioned an RT kernel, I'm curious - did you patch it
 yourself, or is there already an image available? Is it stable, or does it
 randomly freeze?


 I didn't patch it myself, I have been using it in a dozen machines which
 now run consistently ... I have been chasing some issue that was causing
 them to crash after a while, replacing a pile of bash scripts and multiple
 calls to some little dbus CL programs with the same thing directly from C
 in a pd external has fixed the issue .. on the non-RT B+ system as well, so
 it probably was not kernel related.


 here are some notes I've made ... including instructions and links to the
 kernel and files, and sources ... all on my dropbox, and the original link
 I used. They are running notes from a project, so there is a bit of
 extraneous info but download and install instructions are in there:

 https://www.dropbox.com/s/1scwpdufk41k4es/04.setupWolfsonAudio.txt



 Simon

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

Re: [PD] Pd-list Digest, Vol 119, Issue 9

[Brian Fay]

I'm personally curious about how this new Raspberry Pi 2 model compares to
the also pretty new Odroid C1, which is the same price, but seems to have a
slightly faster processor (1.5Ghz quad-core). Has anybody tried one of
those?

On Tue, Feb 3, 2015 at 1:35 PM, Dan Wilcox danomat...@gmail.com wrote:

 I’m curious now. I’ll have to pick one up / borrow one and see if it works
 with my UA-25.
 
 Dan Wilcox
 @danomatika
 danomatika.com
 robotcowboy.com

 On Feb 3, 2015, at 7:30 PM, Miller Puckette m...@ucsd.edu wrote:

 Well, the Pi B+ works fine with the USB audio devices I've tried on it,
 except that I'm suspicious that there is new electrical interference
 (ground trouble perhaps) that I hadn't heard in the earlier Pi B.  But
 I haven't verified that carefully.

 In an ideal world someone would build us an I2S expansion board for Pi
 with 8CH audio in and out, memory mapped straight to user space.  Maybe
 someday someone will build that :)

 Miller

 On Tue, Feb 03, 2015 at 07:20:17PM +0100, Dan Wilcox wrote:

 Does it work with external sound cards nicely now? That’s great if so.
 
 Dan Wilcox
 @danomatika
 danomatika.com http://danomatika.com/
 robotcowboy.com http://robotcowboy.com/

 On Feb 3, 2015, at 6:38 AM, pd-list-requ...@lists.iem.at wrote:

 From: Miller Puckette m...@ucsd.edu mailto:m...@ucsd.edu m...@ucsd.edu
 Cc: pd-list@lists.iem.at mailto:pd-list@lists.iem.at
 pd-list@lists.iem.at pd-list@lists.iem.at 
 mailto:pd-list@lists.iem.at pd-list@lists.iem.at, lhanneuse puredata 
 lhanneusepured...@gmail.com mailto:lhanneusepured...@gmail.com
 lhanneusepured...@gmail.com
 To: Alexandre Torres Porres por...@gmail.com mailto:por...@gmail.com
 por...@gmail.com
 Date: February 3, 2015 at 6:37:51 AM GMT+1
 Subject: Re: [PD] Raspberry pi 2


 Oops - as Max Neupert pointed out to me, the thing I have is the Pi B+,
 not the Pi 2.

 The Pi B+ fixed the USB 2.0 speed problem with audio.  From what I gather
 the Pi 2 will inherit that fix.

 cheers
 Miller



 ___
 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] bandpass or resonant?

[Brian Fay]

 it would behave in a way that I'm
 considering to be an actual resonant filter.

 Now let me go ahead and share a patch that I'm writing for my computer
 music classes. It's about several filters that can be obtained with biquad.
 So I present Pd's vanilla filters such as [lop~], [hip~] and [bp~]. I also
 present externals like [lores~] and [reson~] and I do present all the
 filters from the Audio Eq Cookbook as well. It's in portuguese, and part of
 a big series of examples, but what the hell...

 By the way, I was also able to implement Resonz and Ringz as [biquad~]
 in Pd, but I don't have it on this example (but to hell with supercollider
 already, hehe).

 So there you can check the behaviour and differences that I've pointed.
 For [reson~], I have two separate parameters, one is for Q, and the other
 one, which is originally gain, I'm calling the resonance parameter.
 Much like the resonance parameter in [lores~]...

 As for the Cookbook filters, BPF2 is what I'm calling a regular
 bandpass, and it has a parameter of Q. As for BPF1, I'm calling it a
 resonant filter, and it has a parameter of resonance instead of Q
 (but the idea is that more Q gives more gain/resonance).

 I hope I'm clear in the midst of so much detail and information. It's
 just a stupid doubt on the nomenclature of filters, but this kind of issue
 can be quite a pain in the ass, and the subject of many confusions.

 So, in short, I still keep my original question: Are bandpass and
 resonant filters the same? Or is there a difference between calling one a
 resonant and not a bandpass? Moreover, what about a resonator? Is my
 assumption on how to call one a bandpass and a resonant correct or it
 doesn't have anything to do with the official literature? And how about
 what Julius Smith had to say?

 Cheers

 2015-01-12 20:03 GMT-02:00 Brian Fay ovaltinevor...@gmail.com:

 Based on your posts in this group, you definitely know more about
 filters than I do, so I don't really have an answer to this question - but
 I'm wondering if by resonant filter you mean the same thing as
 resonator filter?

 I saw something interesting earlier today about using resonator filters
 as control sources for FM synthesis:
 http://tai-studio.org/index.php/projects/sound-programming/complexres/

 The paper that is linked in the article has some details on the
 mathematical implementation of the filter, but that's mostly mumbo-jumbo to
 me.

 On Mon, Jan 12, 2015 at 4:24 PM, Alexandre Torres Porres 
 por...@gmail.com wrote:

 Hi, are bandpass and resonant filters the same? Or is there a
 difference between calling one a resonant and not a bandpass?

 thanks

 ___
 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] bandpass or resonant?

[Brian Fay]

Based on your posts in this group, you definitely know more about filters
than I do, so I don't really have an answer to this question - but I'm
wondering if by resonant filter you mean the same thing as resonator
filter?

I saw something interesting earlier today about using resonator filters as
control sources for FM synthesis:
http://tai-studio.org/index.php/projects/sound-programming/complexres/

The paper that is linked in the article has some details on the
mathematical implementation of the filter, but that's mostly mumbo-jumbo to
me.

On Mon, Jan 12, 2015 at 4:24 PM, Alexandre Torres Porres por...@gmail.com
wrote:

 Hi, are bandpass and resonant filters the same? Or is there a difference
 between calling one a resonant and not a bandpass?

 thanks

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

[Brian Fay]

I hadn't even thought of window management, which is obviously pretty
important to the way we currently patch Pd. Thanks for calling that out.
And then of course it would be another matter designing an interface that
would make patching easy on a touchscreen.

It would be great if we could see multiple implementations arise and use
them interchangeably, but I understand there aren't enough man-hours and
expertise available for everything.

On Mon, Jan 5, 2015 at 5:23 PM, Jonathan Wilkes jancs...@yahoo.com wrote:

 I now have a Pd console window running on Node-Webkit, plus some menus.

 The reason I chose Node-Webkit is because all of the bloat includes within
 it what I need to change from tcl/tk, yet still retain the same basic GUI
 interface (and be cross-platform).  Things like creating/destroying new
 windows, adding and disabling menus/menuitems, etc.

 To have even a tiny web server one would have to change the basic design
 to some kind of single-window IDE where you roll your own patch windows.
 That could be very interesting, but it is too much work at this moment.
 However, I am using a sys_vgui wrapper that looks more like pd_vmess.  That
 at least helps to get rid of explicit tcl in the c code, which could help
 going forward with the kind of interface you're talking about.

 -Jonathan


   On Monday, January 5, 2015 4:22 PM, Brian Fay ovaltinevor...@gmail.com
 wrote:


 One thing I really like about a web technology-based interface is the idea
 that maybe the computer running Pd and the computer accessing the interface
 wouldn't necessarily have to be the same computer.

 I'm imagining running Pd on a small single-board computer, and
 patching/interacting with it on a tablet or a phone or a laptop, connecting
 over an ad-hoc wireless network.

 Node-webkit from my understanding is really only intended to run locally,
 as if it were a native application. It includes an implementation of a web
 browser so that it can run, and that is where the ~100MB bloat comes from.

 Maybe instead of relying on node-webkit we could write our own tiny node
 server, and have users jump into their favorite web browsers to access the
 interface?

 This would lose the convenience of starting Pd like a native program, but
 it could be really cool to access it from outside devices.

 Does anybody with more knowledge of Pd's internals have thoughts on the
 feasibility of this?

 -Brian

 On Thu, Jan 1, 2015 at 10:51 PM, Billy Stiltner billy.stilt...@gmail.com
 wrote:




 If GUI manipulation happens only in the GUI thread (i.e., we completely
 separate Pd into GUI thread and audio/message thread), a patch currently
 using [cnv] get_pos method for a crude control surface will break.  This
 is because the coordinate data is only being updated on the GUI side, and
 not reported back to the core.  (Even if the core updates the GUI with
 programmatic coordinate changes.)

 If, on the other hand, the core is changed so that it queries the GUI to
 get coordinate data (for example), you either must block until the GUI
 returns-- which is bad-- or query ansynchrously which breaks determinism--
 which is worse.

 Finally, if you continually send the relevant GUI event data to the Pd


 does webkit provide a submilisecond setInterval()?

 is there anyway to change how tcl/tk responds to input?

 maybe like how in javascript instead of each cell of a table having an
 onClick() ,
 a single loadEventHandler is used foor.
 the entire table, each tcl/tk canvas is kinda like each document element
 in concept.
 anytime user input occurs only controls that respond to that input need
 redrawn. how about 2 different response modes? or 3even.
 1 for patch editing, 1 for performance, and another for dynamic patching?

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

[Brian Fay]

One thing I really like about a web technology-based interface is the idea
that maybe the computer running Pd and the computer accessing the interface
wouldn't necessarily have to be the same computer.

I'm imagining running Pd on a small single-board computer, and
patching/interacting with it on a tablet or a phone or a laptop, connecting
over an ad-hoc wireless network.

Node-webkit from my understanding is really only intended to run locally,
as if it were a native application. It includes an implementation of a web
browser so that it can run, and that is where the ~100MB bloat comes from.

Maybe instead of relying on node-webkit we could write our own tiny node
server, and have users jump into their favorite web browsers to access the
interface?

This would lose the convenience of starting Pd like a native program, but
it could be really cool to access it from outside devices.

Does anybody with more knowledge of Pd's internals have thoughts on the
feasibility of this?

-Brian

On Thu, Jan 1, 2015 at 10:51 PM, Billy Stiltner billy.stilt...@gmail.com
wrote:




 If GUI manipulation happens only in the GUI thread (i.e., we completely
 separate Pd into GUI thread and audio/message thread), a patch currently
 using [cnv] get_pos method for a crude control surface will break.  This
 is because the coordinate data is only being updated on the GUI side, and
 not reported back to the core.  (Even if the core updates the GUI with
 programmatic coordinate changes.)

 If, on the other hand, the core is changed so that it queries the GUI
 to get coordinate data (for example), you either must block until the GUI
 returns-- which is bad-- or query ansynchrously which breaks determinism--
 which is worse.

 Finally, if you continually send the relevant GUI event data to the Pd


 does webkit provide a submilisecond setInterval()?

 is there anyway to change how tcl/tk responds to input?

 maybe like how in javascript instead of each cell of a table having an
 onClick() ,
 a single loadEventHandler is used foor.
 the entire table, each tcl/tk canvas is kinda like each document element
 in concept.
 anytime user input occurs only controls that respond to that input need
 redrawn. how about 2 different response modes? or 3even.
 1 for patch editing, 1 for performance, and another for dynamic patching?

 ___
 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