[PD] question about antialiased canvas on pd-extended osx release

[Ivica Ico Bukvic]

Greetings all,

This is perhaps a bit OT, but I was wondering if the same appearance is
reproducible on Linux as far as the antialiasing of the object boxes,
connector rectangles, cords, and cord colors are concerned? The pd-extended
osx looks IMHO a lot cleaner (I've been running antialiased fonts for a
while now on Linux but having cords and objects also antialiased would
really add to the overall experience).

Many thanks!

Ivica Ico Bukvic, D.M.A.
Composition, Music Technology, CCTAD, CHCI, CS and Art (by courtesy)
Director, DISIS Interactive Sound & Intermedia Studio
Virginia Tech
Dept. of Music - 0240
Blacksburg, VA 24061
(540) 231-6139
(540) 231-5034 (fax)
[EMAIL PROTECTED]
http://www.music.vt.edu/people/faculty/bukvic/
 



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

[PD] curious Pd behavior

[Ivica Ico Bukvic]

Hi all,

In my recent performance, I've noticed a peculiar PD behavior. Now, before I
ask for your advice, please allow me to state that the problem has not been
as pronounced in the past as it was on this performance. Nonetheless, it was
more or less persistent. For this reason, I am asking for your thoughts on
it.

Here's the hw/sw scoop:

AMD64 3000+ laptop
RME HDSP Multiface
Linux 2.6.15 Kernel (real-time enabled, can't recall if it is preempted)
ALSA
JACK
Pd (0.38.4) -rt running MIDI/Display interface for performer/DSP
2 x JACK-RACK with 4 LADSPA plug-ins each
2 x QSynth
The entire setup consistently eats approx. 80% cpu (no spikes).

Pd also had pyext (0.1.3) and a couple of simpler externals (yes, stuff is a
bit outdated...). All audio is diffused (and partially processed) via Pd.

What happens during the runtime is two interesting issues:

1) if I start Pd by clicking on a link (no terminal) the pyext does not
output anything when DSP is on, but as soon as I turn DSP off, it spits out
backlogged data. However, when I start pd from a terminal, everything works
ok. Any ideas as to why?

2) when CPU usage climbs above 50%, Pd starts going out of sync by
initiating opening queue twice which obviously throws entire piece out of
sync. Interestingly, this only happens approx. 50% of the time (randomly).
As the CPU usage grows, it becomes worse. This is not a problem when CPU
usage is lower. Than 50% and never a problem when using built-in soundcard
(this was not a problem before, so it may very well be that it is my setup).

3) when restarting DSP, some of the routed signal going through Pd to the
output is lost at random times. This was in part a problem before as well.

So, while I am aware very much that this may be peculiar to the versions I
used, and/or possibly due to use of a custom (possibly buggy) build of a
kernel, I was wondering if anyone had an alternative explanation for this
kind of behavior.

Many thanks!

Best wishes,

Ivica Ico Bukvic, D.M.A.
Composition, Music Technology, CCTAD, and CHCI (by courtesy)
Virginia Tech
Dept. of Music - 0240
Blacksburg, VA 24061
(540) 231-1137
(540) 231-5034 (fax)
[EMAIL PROTECTED]
http://www.music.vt.edu/people/faculty/bukvic/




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

[PD] Re: pix_video and dv1394 capture on Edgy

[Ivica Ico Bukvic]

A small correction:

apparently device 0 does not work no matter what, but /dev/dv1394/0 works
sometimes but only with black output.

Here's the relevant output from the Pd:

Open example video/00.SimpleVideo.pd

Shell (from which Pd was started): /dev/video0: No such file or directory
(i guess this is expected since ADVC-100 is dv1394 device)

Click on device 0 and driver 1:
No feedback

Start rendering:
Pd window: Direct Rendering enabled!
 GEM: Start rendering
 [pix_videoNEW]: starting transfer
 DV4L: closed
 GL: invalid enumerant
Shell: /dev/ieee1394/dv/host0/NTSC/in: Is a directory

Stop rendering:
Pd window: GEM: Stop rendering

Make message device /dev/dv1394/0, click on it:
Shell: get capabilities: Invalid argument
  get capabilities: Invalid argument (yes, twice)
Pd window: [pix_videoNEW]: device-err: 0

Click on mode NTSC and then driver 1:
Pd window: DV4L: DV decoding quality 5

At this point when I enable the rendering I consistently get (unlike
before):
Pd window: Direct Rendering enabled!
 GEM: Start rendering
 [pix_videoNEW]: starting transfer
 DV4L: closed
 GL: invalid enumerant
Shell: /dev/dv1394/0: Device or resource busy

/dev/raw1394, and /dev/video1394/0 or /dev/video yields invalid argument for
capabilities and does not work.

Again, I would greatly appreciate your insight in this matter before I
resort to switching to a different distro/version.

Many thanks!

Best wishes,

Ico

On 12/27/06, Ivica Ico Bukvic <[EMAIL PROTECTED]> wrote:


Aaaargh, accidentally pressed "send" button...

The only thing left to report is that /dev tree has
dv1394/0
video/0
video -> video/0 symlink
raw1394

Modules loaded are the usual bunch ohci1394 ieee 1394 dv1394 raw1394. I
also tried manually modprobing video1394 with no effect.

/dev/ieee1394  tree is missing but recreating it manually
(/dev/ieee1394/.../in and .../out simply makes "device0" also work with the
same effect as described below.

0.90 gem is worse since it does not allow non-standard choice of devices
but it does not appear to be any better off than the 0.91.

Obviously this suggests that there is something fishy with Edgy, but the
question is what?

Any help is most appreciated!

Best wishes,

Ico

On 12/27/06, Ivica Ico Bukvic <[EMAIL PROTECTED]> wrote:
>
> Hi all,
>
> Here I am 6 months later trying to upgrade my laptop and a new issue has
> cropped up with my video capture in Gem.
>
> System: Ubuntu 6.10 (edgy) i386 using udev
> Graphics: ATI 9600 running fglrx
> Kernel: 2.6.18-rt7
> Video capture: el-cheapo camcorder run through ADVC-100 firewire device
>
> When running Kino, the camera gets captured just fine and everything
> "just works" as expected. However, in Gem (tried 0.90, CVS from November
> and another one from today's snapshot), I need to send following messages
> for Gem capture to work at all:
>
> device /dev/dv1394/0
> mode NTSC
> driver 1
>
> This starts capture reporting DV capture quality at 5, but the captured
> stuff is black. The only proof that things are getting captured comes from
> disconnecting the feed in the middle of the capture by pulling the video
> cable that connects camcorder with the ADVC-100 and then one can notice
> change in the color and/or momentary flicker of the captured area.
>
>
>

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

[PD] Re: pix_video and dv1394 capture on Edgy

[Ivica Ico Bukvic]

Aaaargh, accidentally pressed "send" button...

The only thing left to report is that /dev tree has
dv1394/0
video/0
video -> video/0 symlink
raw1394

Modules loaded are the usual bunch ohci1394 ieee 1394 dv1394 raw1394. I also
tried manually modprobing video1394 with no effect.

/dev/ieee1394  tree is missing but recreating it manually
(/dev/ieee1394/.../in and .../out simply makes "device0" also work with the
same effect as described below.

0.90 gem is worse since it does not allow non-standard choice of devices but
it does not appear to be any better off than the 0.91.

Obviously this suggests that there is something fishy with Edgy, but the
question is what?

Any help is most appreciated!

Best wishes,

Ico

On 12/27/06, Ivica Ico Bukvic <[EMAIL PROTECTED]> wrote:


Hi all,

Here I am 6 months later trying to upgrade my laptop and a new issue has
cropped up with my video capture in Gem.

System: Ubuntu 6.10 (edgy) i386 using udev
Graphics: ATI 9600 running fglrx
Kernel: 2.6.18-rt7
Video capture: el-cheapo camcorder run through ADVC-100 firewire device

When running Kino, the camera gets captured just fine and everything "just
works" as expected. However, in Gem (tried 0.90, CVS from November and
another one from today's snapshot), I need to send following messages for
Gem capture to work at all:

device /dev/dv1394/0
mode NTSC
driver 1

This starts capture reporting DV capture quality at 5, but the captured
stuff is black. The only proof that things are getting captured comes from
disconnecting the feed in the middle of the capture by pulling the video
cable that connects camcorder with the ADVC-100 and then one can notice
change in the color and/or momentary flicker of the captured area.



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

[PD] pix_video and dv1394 capture on Edgy

[Ivica Ico Bukvic]

Hi all,

Here I am 6 months later trying to upgrade my laptop and a new issue has
cropped up with my video capture in Gem.

System: Ubuntu 6.10 (edgy) i386 using udev
Graphics: ATI 9600 running fglrx
Kernel: 2.6.18-rt7
Video capture: el-cheapo camcorder run through ADVC-100 firewire device

When running Kino, the camera gets captured just fine and everything "just
works" as expected. However, in Gem (tried 0.90, CVS from November and
another one from today's snapshot), I need to send following messages for
Gem capture to work at all:

device /dev/dv1394/0
mode NTSC
driver 1

This starts capture reporting DV capture quality at 5, but the captured
stuff is black. The only proof that things are getting captured comes from
disconnecting the feed in the middle of the capture by pulling the video
cable that connects camcorder with the ADVC-100 and then one can notice
change in the color and/or momentary flicker of the captured area.
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] Re: [GEM-dev] Re: pix_video and dv1394 capture on Edgy

[Ivica Ico Bukvic]

Thanks for the advice but I am hoping to avoid webcam due to inherent
quality/fps decrease. Also, what makes me wonder is because Kino works fine
but Gem doesn't and given that Edgy is more-or-less supposed to draw from
the bleeding edge lib versions that this kind of a problem will eventually
trickle down to other distros which may be currently relying upon older
versions of supporting libs, hence requiring update in Gem. If this is so, I
think sooner rather than later is probably a good idea.

Best wishes,

Ico

On 12/28/06, Studio Zodiak <[EMAIL PROTECTED]> wrote:


I tried to get 1394 running with ubuntu edgy without success also.
Maybe try using a webcam before you die of frustration.

I did. It changed my life : )

Sylvain

*I*

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

[PD] Re: [GEM-dev] Re: pix_video and dv1394 capture on Edgy

[Ivica Ico Bukvic]

Thanks for the info. However, ADVC-100 that I use is a firewire A/V device
so the default behavior is 30fps at 720x480 (NTSC) with the only bottleneck
being the quality of the camcorder (which in this case is still better than
a webcam). But all this is moot as Gem worked just fine a month ago when I
was working on Hoary 5.04 and now on 6.10 it doesn't (either the extended
nightly builds or my own build). And this worries me since my project
depends upon transportability/transparency which is currently sorely missing
in this setup...

Best wishes,

Ico

On 12/28/06, Mathieu Bouchard <[EMAIL PROTECTED]> wrote:


On Thu, 28 Dec 2006, Ivica Ico Bukvic wrote:

> Thanks for the advice but I am hoping to avoid webcam due to inherent
> quality/fps decrease.

USB2 is 40 times faster than USB1: at 400 mbps, in 720x576, full color 24
bits per pixel, cameras could do 40 fps... but typically they don't, they
use half the data rate (decimation of chroma columns, as in most broadcast
video) and have a cap at 30 fps because anyway the motion is already
blurry enough at 30 fps.

You may also need a special program to unlock the framerate of the camera.
For Philips cameras (most of the modern Logitech/Labtec) the setpwc
program will allow you to get away from the default framerate of 10 fps.

  _ _ __ ___ _  _ _ ...
| Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju
| Freelance Digital Arts Engineer, Montréal QC Canada

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

[PD] RE: [GEM-dev] Re: pix_video and dv1394 capture on Edgy

[Ivica Ico Bukvic]

> Despite those thoughts I still haven't had a look at unicap yet, still too
> many other things TODO first.

Well, I just wasted another 2 hours trying to get my 5+ (!) year old webcam
working which is still unsupported in Linux (intel pocket pc cam cs780, even
though CS630 and CS430 are supported). Ironically, in Windoze everything
"just worked."

Based on my tests I am suspecting that this is a lib/distro-independent
issue, and as such am also wondering what will happen with pd/gem on Linux
in 6 months when most of the other distros pump out their next release with
libs similar to Edgy (maybe some of them already are?) leaving gem video for
all intents and purposes broken. I also looked at the videojack project
Mathieu pointed out and it really looks, well, promising, but it is by no
means a complete and/or well supported product despite its huge potential.
Perhaps this video issue should be bumped higher on the gem TODO list given
the current situation?

Thanks for all your help!

Best wishes,

Ico


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

[PD] Re: [GEM-dev] Re: pix_video and dv1394 capture on Edgy

[Ivica Ico Bukvic]

As I suspected, issue is much more acute. I just tried the identical setup
on vanilla FC6 and it exhibits *exactly* the same problem (Kino works, but
Gem doesn't using the same ieee1394 device, namely ADVC-100). So, now we
have Dapper, Edgy, and FC6 for sure having this problem and I would not be
surprised to hear that there are more recent distros which exhibit this
issue (Debian for sure due to its relationship to Ubuntu).

Regarding your questions Studio, please see my previous e-mails, they are
pretty verbose as to what is missing and/or what is the behavior. FWIW, I do
not have /dev/dv1394-0, but rather /dev/dv1394/0 device. This is the case on
both FC6 and Ubuntu. The problem is exhibited via pd-extended install,
totally from scratch source install (mine on Ubuntu had everything yes
except for libmpeg1 and ffmpeg; libmpeg3 was also yes), and now also the
CCRMA build.

This may seem that newer udev plus latest ieee1394 libs/drivers are at odds
with the Gem way of addressing them.  I have traced the problem down to
Gem/src/Pixes/videoDV4L.cpp which deals with dv1394 device and from which
all of the errors come. Commenting any of the tripwires simply triggers the
next one (i.e. closed error, then ioctl WAIT_FRAMES, then ioctl GET_STATUS,
etc.). Commenting all "return NULL" evokes these errors on every frame
flodding the shell. I could probably take a stab on this one if I knew more
about ieee1394 and more precisely dv1394 stuff but I don't. Learning so
would take way too much time and more importantly it would be redundant as I
am sure the community already has those who are well-versed in this area. I
will, however, gladly provide necessary access/feedback and even code
provided I am given some help in understanding dv1394 stuff so that the code
is altered accordingly.

I hope you will agree with me that this is a pretty big deal as it will
preclude use of dv1394 in conjunction with Gem without exceptions until this
issue is resolved. My plea is please push this to the top of the TODO list
and I'll do all I can to assist in resolving the issue.

Many thanks!

Best wishes,

Ico

On 12/28/06, Studio Zodiak <[EMAIL PROTECTED]> wrote:


This is interesting.
Like I said before,
I asked this list before with the same problem.

maybe we can share info.

Are you compiling Gem?

I have used the compiling options --with-ieee1394-includes
and --with-ieee1394-libs
-I don't know where to set the libs thaugh- /usr/lib/?

Anyway, at the end of the configure, I get no for the ieee1394 option.

even disabling v4l is not doing much.

I went on the ieee1394 website and saw that the api relies on two
libraries.

Just for you information,
last time I succeeded in making my dvcamera work with Gem on linux was on
red hat 9.

This I have tried on breezy and dapper with no success.

I grepped for /dev/ieee1394 in the Gem's src directory and found that it
is supposed to default to ieee1394 from v4l (is this correct?).

I remember having to send a driver 1 message to pix_video like on a mac.

Only on my Edgy machine the repertoire is /dev/ieee1394-0

could one do as such perhaps?

1. ln -s /dev/ieee1394 /dev/ieee1394-0

2. permissions

Anyway, just my 2 cents for now.

Sylvain







*Ivica Ico Bukvic <[EMAIL PROTECTED]>* wrote:

> Despite those thoughts I still haven't had a look at unicap yet, still
too
> many other things TODO first.

Well, I just wasted another 2 hours trying to get my 5+ (!) year old
webcam
working which is still unsupported in Linux (intel pocket pc cam cs780,
even
though CS630 and CS430 are supported). Ironically, in Windoze everything
"just worked."

Based on my tests I am suspecting that this is a lib/distro-independent
issue, and as such am also wondering what will happen with pd/gem on Linux
in 6 months when most of the other distros pump out their next release
with
libs similar to Edgy (maybe some of them already are?) leaving gem video
for
all intents and purposes broken. I also looked at the videojack project
Mathieu pointed out and it really looks, well, promising, but it is by no
means a complete and/or well supported product despite its huge potential.
Perhaps this video issue should be bumped higher on the gem TODO list
given
the current situation?

Thanks for all your help!

Best wishes,

Ico


___
GEM-dev mailing list
[EMAIL PROTECTED]
http://lists.puredata.info/listinfo/gem-dev


__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

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

[PD] Re: [GEM-dev] Re: pix_video and dv1394 capture on Edgy

[Ivica Ico Bukvic]

FWIW, here are some pointers that may help. I just investigated kino package
which apparently works and the same site hosts a very simple dvgrab shell
app which captures dv stream into an avi file. At a first glance it appears
simple enough to be adapted for Gem use, but I may be totally wrong about
this too... Now, if someone could please point out what kind of packets does
videoDV4L.cpp send out to Gem...

Best wishes,

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

[PD] pix_video and dv1394 capture on Dapper/Edgy/FC6

[Ivica Ico Bukvic]

Well, here are my latest findings. I just spent 2 days trying to hack the
dvgrab app (available from Kino, talks to devices via userland) and somehow
merge it with Gem. I am pleased to report that the hackathon was successful
but the results were surprisingly the same as before (talk about the DOH!
moment). However, I did discover that actually both before and now the video
feed *was* working. It is however as if the entire texture in Gem is
covering either really small area (i.e. one pixel) or had some kind of
mangled data that remained for the most part black. How do I know this? When
I flickered with my hand in front of the camera and/or made drastic changes
in lighting/exposure, there was slight change in color of the overall
texture. 

So what gives? It obviously is not the way Gem tries to open devices as this
other userland model had no effect on the final results, but there is simply
something that prevents the texture to be projected properly. Granted, I
reused as much of the old code as possible but the core of the engine was
going through dvgrab which in and of itself works flawlessly.

So, given that Dapper/Edgy/FC6 all suffer from this (all of whom are new
distros), is it:

1) udev (unlikely since devices open ok)
2) updated fw driver which somehow messes something up (unlikely since Kino
works)
3) way how Gem talks to fw devices (unlikely since it apparently works)
4) something with imageStruct or some other GL-texture related thing
(unlikely since 0.90 release behaves the same)
5) something else but what?

The only obvious commonality is that all distros are new. Other than that, I
have no clue whatsoever...

At this point I am also wondering if Linux Gem and more specifically dv part
of it is actively maintained and if so by whom? Furthermore, I would love to
hear from others who are using Gem/DV in their work in order to figure out
whether this affects any other recent distro/setup.

If anyone is interested in testing this other hacked version I'll gladly
post it but please note that it is built with scotch tape and chewing gum.

Naturally, I am hoping for some help in this area since I am at a loss what
may be wrong...

Best wishes,

Ico



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

Re: [PD] pix_video and dv1394 capture on Dapper/Edgy/FC6

[Ivica Ico Bukvic]

One word: WOW!

This, against any common sense actually worked. On Ubuntu Hoary running on
the 100% same hardware and the *same* pd software revision this was not
needed. Now suddenly this is required, go figure. More so, given that
e-mails on various lists asking about this go back to mid-2005, none of
which were apparently solved...

So, in short for Studio and others to try out:

1) Start the examples/Gem/04.Video/00.SimpleVideo.pd
2) Change device message to "/dev/dv1394/0" or if you have dv1394-0 device,
then to "/dev/dv1394-0"
3) Change "driver 0" to "driver 1"
4) add a message to pix_texture "mode 0"
5) depending upon your type of camera you may also need to use "mode NTSC"

Click on mode (if needed), then driver, then device, then on the newly added
mode, and then finally create gemwin and turn on rendering. You should now
have a working dv feed!

Kudos to Chris for solving the riddle! I am still a bit confused why this is
necessary (mode deals with "rectangle texturing" but since I was using the
same version of pd/gem before and it worked without it, this is still IMHO
very curious).

Best wishes,

Ico

On 12/31/06, chris clepper <[EMAIL PROTECTED]> wrote:


send 'mode 0' to pix_texture?

On 12/30/06, Ivica Ico Bukvic <[EMAIL PROTECTED]> wrote:
>
> Well, here are my latest findings. I just spent 2 days trying to hack
> the
> dvgrab app (available from Kino, talks to devices via userland) and
> somehow
> merge it with Gem. I am pleased to report that the hackathon was
> successful
> but the results were surprisingly the same as before (talk about the
> DOH!
> moment). However, I did discover that actually both before and now the
> video
> feed *was* working. It is however as if the entire texture in Gem is
> covering either really small area (i.e. one pixel) or had some kind of
> mangled data that remained for the most part black. How do I know this?
> When
> I flickered with my hand in front of the camera and/or made drastic
> changes
> in lighting/exposure, there was slight change in color of the overall
> texture.
>
>
>

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

Re: [PD] pix_video and dv1394 capture on Dapper/Edgy/FC6

[Ivica Ico Bukvic]

On 12/31/06, chris clepper <[EMAIL PROTECTED]> wrote:

On 12/31/06, Ivica Ico Bukvic <[EMAIL PROTECTED]> wrote:
> I am still a bit confused why this is necessary (mode deals with
"rectangle texturing" but since I was using the same version of pd/gem
before and it worked without it, this is still IMHO very curious).

Did any graphics drivers change?  There seems to be a problem with some
configurations where rectangle textures are listed as supported but the
texture coordinates for them are not dealt with properly.  Coordinates for
rectangle textures are absolute pixel dimensions while 2D textures are
normalized from 0..1, which is why the rectangle coordinates give the one
big pixel effect.


Well, in my case the distro was upgraded from 5.04 to 6.10 which is a
pretty significant leap forward (kernel 2.6.5-ish to 2.6.18), so I am
quite confident that drivers have been updated all across the board.
Given that this is a dv issue, my guess would be the ieee1394 driver,
especially since the project website reports a major overhaul of the
driver for the 2.6.12 kernel series and up.

BTW, are there any sideffects of running pix_texture this way or is
this pretty much a transparent fix for this setup?

Again, many thanks for your help in this matter!

P.S. Perhaps it would be nice to overhaul the documentation to reflect
this important issue (it would've saved me 2 1/2 days of hacking :-)
and if googling is any indicator of the current state I am sure others
may benefit from it too. I'll gladly supply a new patch if someone
could upload it to Gem CVS since I do not have dev access to it.

Best wishes,

Ico

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

Re: [PD] pix_video and dv1394 capture on Dapper/Edgy/FC6

[Ivica Ico Bukvic]

I'll have a look at the pix_texture code in the near future and see if we
can improve the default settings for texturing on each platform.


If "mode" thingy is going to go away by altering pix_texture then
obviously changes in docs will not be necessary. Otherwise, I am quite
convinced that updating documentation might be a good idea.

Once again, many thanks for your help and a Happy New Year to all!

Best wishes,

Ico

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

[PD] looking for an example port of a max/msp external to flext

[Ivica Ico Bukvic]

Hi all,

Does anyone know of a simple external port example from Max/MSP into
flext/Pd? It seems that this is not a very common route so I am looking for
some preferably simple external for my student to be able to compare code in
order to learn more about the process and ultimately figure out how to port
such externals to Pd via flext.

Any help is most appreciated!

Best wishes,

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

RE: [PD] looking for an example port of a max/msp external to flext

[Ivica Ico Bukvic]

I am aware of that but we are in a situation where we wish to port a Max/MSP
external to PD and are opting to going with flext because if we do this,
then the original maintainers won't have to deal with two different code
bases and as such are more likely to opt for maintaining flext port
themselves.

So, what we need is an example of a simple port from Max/MSP external to see
what are relationships between the two, knowing that it may not be as
straightforward as originally thought.

Hope this clarifies things a bit.

Ico

> -Original Message-
> From: Kyle Klipowicz [mailto:[EMAIL PROTECTED]
> Sent: Monday, February 19, 2007 6:01 PM
> To: Ivica Ico Bukvic
> Cc: pd-list@iem.at; [EMAIL PROTECTED]
> Subject: Re: [PD] looking for an example port of a max/msp external to
> flext
> 
> I think (and others may correct me) that flext is more for creating
> externals that work for either Pd or Max/MSP. That is, using the flext
> framework from the get-go will provide a very portable external
> package.
> 
> I don't believe that flext will add any ease to making an external
> that was written without it (flext) available for Pd from Max or vice
> versa.
> 
> Anyone?
> 
> ~Kyle
> 
> On 2/19/07, Ivica Ico Bukvic <[EMAIL PROTECTED]> wrote:
> > Hi all,
> >
> > Does anyone know of a simple external port example from Max/MSP into
> > flext/Pd? It seems that this is not a very common route so I am looking
> for
> > some preferably simple external for my student to be able to compare
> code in
> > order to learn more about the process and ultimately figure out how to
> port
> > such externals to Pd via flext.
> >
> > Any help is most appreciated!
> >
> > Best wishes,
> >
> > Ico
> >
> > ___
> > PD-list@iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> > http://lists.puredata.info/listinfo/pd-list
> >
> >
> 
> 
> --
> 
> http://theradioproject.com
> http://perhapsidid.blogspot.com
> 
> (()()()(()))()()())(
> (())(())()(((
> ))(__
> _())(()))___
> (((000)))oOO


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

[PD] RE: [PD-dev] tcl/tk 8.5, antialising, and large fonts lead to huge cpu overhead bug?

[Ivica Ico Bukvic]

You are absolutely right from a pragmatic perspective. However, having 100
refreshes top off a relatively recent CPU is quite worrisome and IMHO should
not be dismissed lightly as it could manifest in other contexts as well.
FWIW I did a program which had a similar feature in Qt over four years ago
(with 100Hz refreshes for several concurrent timers) and its CPU usage was
always less than 3% at that time. This either suggests that Tcl/Tk is a
total hog or that there is a bug in a code somewhere (or both).

Hence me bringing this up...

Ico

> -Original Message-
> From: Hans-Christoph Steiner [mailto:[EMAIL PROTECTED]
> Sent: Monday, February 19, 2007 10:22 PM
> To: [EMAIL PROTECTED]
> Cc: pd-dev@iem.at
> Subject: Re: [PD-dev] tcl/tk 8.5, antialising, and large fonts lead to
> huge cpu overhead bug?
> 
> 
> Sounds like you are charting new territory.  I haven't worked with
> Tcl/Tk 8.5 yet, but I think a couple people on the list have.
> 
> I don't know of any reason to update a GUI object more than 100 Hz
> since that's about the max for screen refreshes.  10 Hz is probably
> faster than we can perceive numbers anyway.
> 
> .hc
> 
> On Feb 18, 2007, at 11:03 PM, [EMAIL PROTECTED] wrote:
> 
> > All right, unlike my previous e-mail this is perhaps not a bug, but
> > an oddity.
> > Nonetheless, it would be nice to know at least where it is stemming
> > from so
> > that I can contribute code in the right place...
> >
> > I've encountered unusual spike in cpu use when using antialiased
> > tcl/tk 8.5
> > (IIRC it also affects other antialiasing-enabled tcl/tk releases) in
> > conjunction with large fonts. I for instance use this for my
> > performers so that
> > they can clearly read info even when positioned at some distance
> > from the
> > display monitor/LCD.
> >
> > One quick example would be to use a large font counter which counts
> > 1/100ths of
> > a second using metro and displaying it in a number2 object. This
> > results in a
> > 80+% (!) CPU utilization on an Athlon 64 3000+. Lowering metro to
> > 1/10th of
> > second drops CPU use below 5%. Similarly making font smaller does
> > the same.
> > Font size used is in this case is just about anything above 72.
> >
> > Any ideas how to circumvent this problem? Is this due to antialiasing
> > inefficiency in tcl/tk or some other reason? If I can be pointed in
> > the right
> > direction, I'll gladly provide patches...
> >
> > Best wishes,
> >
> > Ivica Ico Bukvic, D.M.A.
> > Composition, Music Technology, CCTAD, CHCI
> > Virginia Tech
> > Department of Music
> > Blacksburg, VA 24061-240
> > (540) 231-1137
> > (540) 231-5034 (fax)
> > ico.bukvic.net
> >
> > ___
> > PD-dev mailing list
> > PD-dev@iem.at
> > http://lists.puredata.info/listinfo/pd-dev
> 
> 
> 
> 
> 
> If you are not part of the solution, you are part of the problem.



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

RE: [PD] looking for an example port of a max/msp external to flext

[Ivica Ico Bukvic]

The problem is that we are trying to get a Max/MSP external ported into
flext, not directly to Pd (but obviously flext version would work fine for
both Pd and Max). In this scenario dealing with something that is done the
other way around is not as helpful for a newcomer to the flext.

Also, forgot to mention preferred examples would be signal-based...

All that being said, I guess whatever you might have should prove to be
better than nothing.

Many thanks!

Ico

> -Original Message-
> From: Stefano Papetti [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, February 20, 2007 6:29 AM
> To: Ivica Ico Bukvic
> Cc: pd-list@iem.at; [EMAIL PROTECTED]
> Subject: Re: [PD] looking for an example port of a max/msp external to
> flext
> 
> Hi,
> 
> I ported some pd externals to Max using flext. Do you think they would be
> useful? Otherwise look at the flext tutorial: there you'll find several
> examples of flext-based externals corresponding to some of the pd
> externals
> supplied with the HOWTO for pd (http://iem.at/pd/externals-HOWTO/).
> 
> Best,
> Stefano
> 
> 
> On Mon, February 19, 2007 22:44, Ivica Ico Bukvic said:
> > Hi all,
> >
> > Does anyone know of a simple external port example from Max/MSP into
> > flext/Pd? It seems that this is not a very common route so I am looking
> for
> > some preferably simple external for my student to be able to compare
> code in
> > order to learn more about the process and ultimately figure out how to
> port
> > such externals to Pd via flext.
> >
> > Any help is most appreciated!
> >
> > Best wishes,
> >
> > Ico
> >


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

Re: [PD] looking for an example port of a max/msp external to flext

[Ivica Ico Bukvic]

Using flext?

Ico

> -Original Message-
> From: Hans-Christoph Steiner [mailto:[EMAIL PROTECTED]
> Sent: Monday, February 19, 2007 10:10 PM
> To: Ivica Ico Bukvic
> Cc: 'Kyle Klipowicz'; pd-list@iem.at; [EMAIL PROTECTED]
> Subject: Re: [PD] looking for an example port of a max/msp external to
> flext
> 
> 
> In CVS:
> 
> externals/io/wiiremote
> externals/io/hidio (pretty rough still)
> externals/boids
> externals/olafmatt/flashserver
> 
> Those are all Max->Pd ports.
> 
> .hc
> 
> 
> On Feb 19, 2007, at 6:19 PM, Ivica Ico Bukvic wrote:
> 
> > I am aware of that but we are in a situation where we wish to port
> > a Max/MSP
> > external to PD and are opting to going with flext because if we do
> > this,
> > then the original maintainers won't have to deal with two different
> > code
> > bases and as such are more likely to opt for maintaining flext port
> > themselves.
> >
> > So, what we need is an example of a simple port from Max/MSP
> > external to see
> > what are relationships between the two, knowing that it may not be as
> > straightforward as originally thought.
> >
> > Hope this clarifies things a bit.
> >
> > Ico
> >
> >> -Original Message-
> >> From: Kyle Klipowicz [mailto:[EMAIL PROTECTED]
> >> Sent: Monday, February 19, 2007 6:01 PM
> >> To: Ivica Ico Bukvic
> >> Cc: pd-list@iem.at; [EMAIL PROTECTED]
> >> Subject: Re: [PD] looking for an example port of a max/msp
> >> external to
> >> flext
> >>
> >> I think (and others may correct me) that flext is more for creating
> >> externals that work for either Pd or Max/MSP. That is, using the
> >> flext
> >> framework from the get-go will provide a very portable external
> >> package.
> >>
> >> I don't believe that flext will add any ease to making an external
> >> that was written without it (flext) available for Pd from Max or vice
> >> versa.
> >>
> >> Anyone?
> >>
> >> ~Kyle
> >>
> >> On 2/19/07, Ivica Ico Bukvic <[EMAIL PROTECTED]> wrote:
> >>> Hi all,
> >>>
> >>> Does anyone know of a simple external port example from Max/MSP into
> >>> flext/Pd? It seems that this is not a very common route so I am
> >>> looking
> >> for
> >>> some preferably simple external for my student to be able to compare
> >> code in
> >>> order to learn more about the process and ultimately figure out
> >>> how to
> >> port
> >>> such externals to Pd via flext.
> >>>
> >>> Any help is most appreciated!
> >>>
> >>> Best wishes,
> >>>
> >>> Ico
> >>>
> >>> ___
> >>> PD-list@iem.at mailing list
> >>> UNSUBSCRIBE and account-management ->
> >>> http://lists.puredata.info/listinfo/pd-list
> >>>
> >>>
> >>
> >>
> >> --
> >>
> >> http://theradioproject.com
> >> http://perhapsidid.blogspot.com
> >>
> >> (()()()(()))()()())(
> >> (())(())()(((
> >> ))(__
> >> _())(()))___
> >> (((000)))oOO
> >
> >
> > ___
> > PD-list@iem.at mailing list
> > UNSUBSCRIBE and account-management -> http://lists.puredata.info/
> > listinfo/pd-list
> 
> 
> 
> 
> The arc of history bends towards justice. - Dr. Martin Luther
> King, Jr.



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

Re: [PD] [PD-dev] tcl/tk 8.5, antialising, and large fonts lead to huge cpu overhead bug?

[Ivica Ico Bukvic]

> You're right, it definitely shouldn't be that bad.  Have you tried
> this same test on different platforms, or with different versions of
> Tcl/Tk?  (I am guessing you are on Windows, which I don't use).  I

Nope. I am on a Linux box (not literally at this very moment, but I use PD
exclusively on Linux). I did try this on 2 different machines with same
results. Although both of them were AMD cpus (3000+ laptop and a 4800+
desktop, nicely loaded in terms of RAM etc.), since your test below was on a
totally different architecture, my hunch is that this has nothing to do with
cpu choice. The two also used two different distros.

> just tried on my G4 800 with Tcl/Tk 8.4.15-cvs.  I get about 50%
> usage from one num2 at 24 point at 100hz.

Is this with antialiased fonts? Either way, what we have so far suggests
that the tcl/tk is a real hog. With GriPD being apparently abandonware,
should one simply use Gem to display data that calls for refreshes faster
than 10Hz? To me this idea sounds like an overkill...

Ico


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

Re: [PD] Percolate

[Ivica Ico Bukvic]

Hi all,

Given the recent discussion, here's some ahead notice (FWIW). I am currently
working with my GTA on completing the port of the munger~ object which is a
part of the Percolate lib but is also broken in the old Pd port. The port is
flext-based which will allow the original author to continue its maintenance
in a platform-agnostic way. The current status is that it is fully
operational and based off of the 0.9beta5. The only thing remaining is to
port elements found in the beta6 and release it. We should be hopefully
releasing this object in the next couple of days.

Best wishes,

Ico



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

Re: [PD] Percolate

[Ivica Ico Bukvic]

I know Dan very well, he's a really cool guy. Luke less so, however. FWIW, I
can ask him to see if he would not mind altering license a bit to allow its
inclusion in the pd cvs.

Best wishes,

Ico

> -Original Message-
> From: Kevin McCoy [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, March 06, 2007 5:51 PM
> To: Ivica Ico Bukvic; PD-list@iem.at; [EMAIL PROTECTED]
> Subject: Re: [PD] Percolate
> 
> This is encouraging, as munger~ is really the object I want to use the
> most.  My opinion is keep going even if we don't figure out the
> licensing right away.  I'm just starting to realize what a conundrum
> licensing could be.
> 
> Has anyone considered contacting the original authors and requesting
> GPL licensing?  Is there any other kind of permission we could seek?
> 
> Also, what about derivative code?  I have little knowledge about the
> differences in these licenses, so if someone could point out a
> particularly lucid article that would be tight.
> 
> Kevin
> 
> On 3/6/07, Ivica Ico Bukvic <[EMAIL PROTECTED]> wrote:
> > Hi all,
> >
> > Given the recent discussion, here's some ahead notice (FWIW). I am
> currently
> > working with my GTA on completing the port of the munger~ object which
> is a
> > part of the Percolate lib but is also broken in the old Pd port. The
> port is
> > flext-based which will allow the original author to continue its
> maintenance
> > in a platform-agnostic way. The current status is that it is fully
> > operational and based off of the 0.9beta5. The only thing remaining is
> to
> > port elements found in the beta6 and release it. We should be hopefully
> > releasing this object in the next couple of days.
> >
> > Best wishes,
> >
> > Ico
> >
> >
> >
> > ___
> > PD-list@iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
> >
> 
> 
> --
> 
> 
> 
> http://pocketkm.blogspot.com


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

Re: [PD] Percolate

[Ivica Ico Bukvic]

>I didn't check, but isn't munger~ licensed with the "no commercial,
>educational only" clause? If yes, then you might run into legal
>trouble because flext is GPL and the two licenses would be way
>incompatible.

Hi Frank,

Well I am "educational only" currently so no problem there. Apart from that
I know Dan well and he is AFAIK all in support of this effort. I am also
currently discussing with him and Luke whether we could adjust Percolate
license to have it include in PD. At least as far as munger~ object is
concerned, this may not be a problem (don't know for sure yet, though). But
the rest of the external does have some stuff that may belong to Yamaha
patent-wise, so I am not sure how that will play itself out. Will keep you
posted...

Best wishes,

Ico




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

Re: [PD] Percolate

[Ivica Ico Bukvic]

> I know Dan very well, he's a really cool guy. Luke less so, however. FWIW,

I just realized how awkward this sounded. Sorry all, especially my sincere
apologies to Luke if he is reading this. My proofreading
has gone down the drain since I began averaging 30+ e-mails a
day...

What I meant to say is that both Luke and Dan are very cool guys, I just
don't know Luke as well as I do know Dan...

Ico 


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

Re: [PD] Percolate

[Ivica Ico Bukvic]

Oh, please try! Having percolate's non-STK objects available would be
so lovely. I'm sure it's not in their intention to keep percolate from
being used in open source projects just because of a hairy license
issue, but they are the only ones who could do something about it.



BTW, the latest version of munger~ 0.9beta6 is STK-dependent. The one we
have currently built and is working just fine isn't (this one is based off
of 0.9beta5). FWIW, you can always compile flext with stk... Alternately, a
couple ifdefs should do the trick...

Best wishes,

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

Re: [PD] Percolate

[Ivica Ico Bukvic]

> That's not the problem. The problem is, that the current Percolate
> license is not a free software license. Non-free licenses are
> incompatible with the GPL, which flext uses. By distributing a version
> of Percolate externals using their current license built with
> GPL-flext you would be violating the GPL! So you are not allowed to
> distribute your flext-Percolate ATM.

Please pardon my ignorance, but will this be the case even if I distribute
the ported code as source-only (assuming that I get a permission to do so
from the original authors)? Also, how does this affect Stk+flext, since
Stk's license is not GPL either?

Best wishes,

Ico


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

Re: [PD] Percolate

[Ivica Ico Bukvic]

> I'm not a lawyer, but as I understand it, source or binary doesn't
> matter: As long as you distribute a flext-external, source or binary,
> you have to distribute it as GPL. This is impossible without violating
> either the Percolate license or the GPL, because both are
> incompatible: the Percolate license isn't a free license.
> 
> > Also, how does this affect Stk+flext, since Stk's license is not GPL
> > either?
> 
> The Stk-license is perfectly compatible with the GPL, it's almost a
> public domain license and doesn't try to restrict use and distributiom
> in a way, as Percolate's license does. So there are no problems
> linking flext and stk.

While I can see your point, one thing that confuses the heck out of me is
the following excerpt from the STK license:

"Some of the concepts are covered by various patents, some known to us and
likely others which are unknown.  Many of the ones known to us are
administered by the Stanford Office of Technology and Licensing."

Obviously, I am not a lawyer either, but I thought that GPL was not
patent-compatible. If someone's source is potentially infringing upon a
patent, (which I am not claiming that STK is--I am speaking here purely
hypothetically), my rather limited [mis]understanding of licenses is that
they do not have the right to grant permissions to others to use patented
code of a patent that is not theirs...

This is why I thought that "educational use" ought to do it, but then again,
what do I know? ;-)

Best wishes,

Ico



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

[PD] ANN: munger1~ port (from the Percolate library)

[Ivica Ico Bukvic]

Hi all,

For impatient, download at: http://ico.bukvic.net/Max/munger1~_1.0.0.tar.gz
(270KB, includes source, Linux-Pd-i386, Mac-Max-i386, and Win32-Max-i386
binaries, and 3 cases of beer)

OVERVIEW


munger1~ (March 12, 2007 1.0.0 release)
a realtime multichannel granulator
a.k.a. the swiss-army-knife of realtime granular synthesis

a flext (cross-platform PD & Max/MSP) port of
the munger~ object from the PeRColate library (0.9 beta5)
http://www.music.columbia.edu/PeRColate/

Original PeRColate library by:

Dan Trueman http://www.music.princeton.edu/~dan/
R. Luke DuBois's http://www.lukedubois.com/

Flext port and additions by:
Ivica Ico Bukvic http://ico.bukvic.net
Ji-Sun Kim [EMAIL PROTECTED]
http://www.music.vt.edu 
http://www.cctad.vt.edu

Released under GPL license
(whichever is the latest version--as of this release, version 2)
For more info on the GPL license please visit:
http://www.gnu.org/copyleft/gpl.html

ACKNOWLEDGEMENTS


Many thanks to Dan Trueman for open-sourcing this great object!

SOURCE INSTALL
==

If you simply intend to use prebuilt binaries, please skip to the INSTALL
section. Otherwise take a big breath and read on...

1) You need stk library which can be downloaded from:

http://ccrma.stanford.edu/software/stk/

2) You need to also install latest flext library (this is a library that
allows for creation of externals for both Max/MSP and PD using the same
source). Version 0.4.x can obtained from the following link:

http://g.org/ext/flext/

Latest CVS version (0.5.1) is found in the Pure-Data CVS (this one is
recommended):

http://sourceforge.net/cvs/?group_id=55736

3) If you are using latest CVS version (0.5.1) Before compiling the source
you will need to add the following to the top of the flext/source/flstk.h
file right below the #define __FLSTK_H:

#ifdef PI
#undef PI
#endif

This step will probably become quickly obsolete once Thomas updates CVS.
Until then, this is needed to be able to compile flext against stk.

4) To compile flext, read flext instructions (it boils down to running
build.sh with appropriate parameters and then editing two simple config
files, i.e. "build pd gcc build" or "build max gcc" or "build max msvc"
etc.)

Your will need to edit buildsys/config-.txt to
adjust paths to various folders.

Then you will need to edit config.txt file. You do not need to include
SndObj for this external but you do need stk option to be properly set. On
Windows+MSVC, STK flag at the time of this release does not work, so you
will have to use included testmunger1 MSVC project file and adjust path
settings to compile munger1~.

5) Once stk and flext are compiled, go into munger1~ folder and type:

/build.sh   

NB: on Mac  is not needed. On Windows, please use MSVC
and open the testmunger1 project file in the root of the folder.

6) Once compiled, your binary will be created in a 
subfolder (i.e. pd-linux, or max-darwin), followed by another subfolder
which reflects whether a threaded or singlethread flext was used. Inside you
will find your external.

INSTALL
===

You can either use the prebuilt externals (found in the bin/ folder) or ones
built using the "SOURCE INSTALL" instructions above. Binaries are provided
for Intel-based Macs, Win32, and Intel-based Linux OS. The included prebuilt
binaries DO NOT REQUIRE you to install flext or stk as these are statically
linked.

1) Copy the external in your externals folder (i.e. /usr/lib/pd/extra or
C:\Program Files\Cycling '74\MaxMSP 4.6\Cycling '74\externals\, or
"Applications/MaxMSP 4.6/Cycling '74/externals)

2) Copy appropriate help file (found in the help/ folder) into the help
folder (i.e. /usr/lib/pd/doc/5.reference or C:\Program Files\Cycling
'74\MaxMSP 4.6\max-help, or "Applications/MaxMSP 4.6/max-help)

NB: Pd help file has a ".pd" extension, while Max/MSP help file has a
".help" extension.

3) Start your app (PD or Max) and create object called munger1~. Right-click
(ctrl-click on Macs) and select "help" and this should open the help file
with additional documentation.

Questions? See OVERVIEW for contact and Q&A info.

Enjoy!

FAQ
===

The following is Ico's FAQ, so it may or may not reflect other project
participants' opinions, including original author(s) of munger~, flext, etc.

Q: Why porting to flext?
A: Flext library (by Thomas Grill) is a layer which allows creation of
externals for both Max/MSP and PD without any alterations to the code
(obviously once it is adapted to use flext). While there have been a number
of Max/MSP <-> PD external ports in the past, many of them have become
outdated because such attempts required either maintaining one code full of
ugly #ifdefs, or worse--maintaining two sources. Either way, what usually
turned out to be the case is that original authors did not have the time,
interest, or simply the softwar

Re: [PD] ANN: munger1~ port (from the Percolate library)

[Ivica Ico Bukvic]

> I was wondering what this object does. So i downloaded  it to see the
> help patch, as suggested. But it is fairly hard not to get lost, as
> there are so much info on little space. My suggestion is to chunk it
> in bits. (And make a counter sub-patch instead of using a counter
> object.)

If you feel that the help patch is not comprehensive/understandable enough,
your contributions to cleaning this up are most appreciated. I unfortunately
have to move on to putting out the next fire on my calendar...

Best wishes,

Ico


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

Re: [PD] ANN: munger1~ port (from the Percolate library)

[Ivica Ico Bukvic]

> OK after running the build script for flext for the first time I get a
> config-mac-pd-gcc.txt file, but I do not see this other config.txt
> file to edit...?
> 
> Using flext 0.5.1 on iMac G5 10.4.8

Re-run the same build.sh script again to create it (you'll have to run
build.sh several times). If in doubt, please post on flext list (or, if
everything else fails, read the README included with flext).

Best wishes,

Ico


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

Re: [PD] ANN: munger1~ port (from the Percolate library)

[Ivica Ico Bukvic]

> just to understand: the win munger1~ PD binary is not
>  included, right? (I only see a .mxe...)
> Do you have plans to include it in the future
> (I do not have flext on win at the moment) ?
> 
> Thanks for sharing this work.
> 
> regards,

You can build it yourself. It shouldn't be too hard. Instructions are
included in the Readme.

Best wishes,

Ico


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

Re: [PD] ANN: munger1~ port (from the Percolate library)

[Ivica Ico Bukvic]

> Just to let you know a couple of things:
> 
> I'm excited to use this object but compiling flext against STK is
> proving to be quite irritating.  After the modifications you suggest
> to flstk.h, I am getting the following error:
> 
> /usr/bin/libtool: can't locate file for: -lstk
> /usr/bin/libtool: file: -lstk is not an object file (not allowed in a
> library)
> make[1]: *** [pd-darwin/release-shared/libflext-pd.0.5.1.dylib] Error 1
> make: *** [build-release-shared] Error 2

You need to make sure that your stk.lib is installed somewhere on your
system that is in your PATH. In other words, when you compile stk.lib, you
should copy this into /usr/local/lib (or somewhere like that). You should
also have stk include/ folder copied into a similar location (i.e.
/usr/local/include/stk or something similar).

Alternately, you should make sure that your package.txt paths are adjusted
to reflect exact locations of these files. For further reading, please see
flext documentation (buildsys/readme.txt) which gives you additional
variables for package.txt (if I recall correctly, apart from INCPATH, there
might be also LIBPATH or something similar).

> This is not your fault, obviously :) I will post this to the flext
> list if I can't find anything searching.
> 
> So I cannot compile munger1~ yet until I get a working flext/STK
> install.  However, I noticed a small mistake in your readme:  The
> instructions say to go into the munger1~ and execute flext's build.sh
> script, but it can actually only be executed from your source
> directory because it needs the package.txt file to run.  So I made the
> correction and turned it into:
> 
> 5) Once stk and flext are compiled, go into munger1~ folder, cd to the
> source directory, and type:
> 
> /build.sh  
> 

This is what original README says anyhow so I am not quite sure what part of
the README you are referring to.  should precede
build.sh.

Best wishes,

Ico


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

[PD] ANN: munger1~ minor update

[Ivica Ico Bukvic]

http://ico.bukvic.net/Max/munger1~_1.0.1.tar.gz

(includes changelog and install how-to documentation fixes)

Best wishes,

Ivica Ico Bukvic, D.M.A.
Composition, Music Technology, CCTAD, and CHCI
Virginia Tech
Dept. of Music - 0240
Blacksburg, VA 24061
(540) 231-1137
(540) 231-5034 (fax)
[EMAIL PROTECTED]
http://www.music.vt.edu/people/faculty/bukvic/


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

Re: [PD] ANN: munger1~ port (from the Percolate library)

[Ivica Ico Bukvic]

> I had a veeery big breath before start compiling
> flext/stk & munger1~ :-). Unfortunately I had the
> same results as Kevin on Win32 (cygwin):
> 
> ...
> [lots of compilation stuff here]
> ...
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld:
> cannot find -lstk
> collect2: ld returned 1 exit status
> make[1]: *** [pd-cygwin/release-shared/libflext-pd.dll] Error 1
> make[1]: Leaving directory `/cygdrive/d/zin/my_install/flext'
> make: *** [build-release-shared] Error 2
> 
> Note: I got successful compilation of flext without stk,
> the previous error was obtained by compiling flext against
> stk.
> 
> I definitely need more time to understand
> the flext/stk stuff before going into munger1..
> I'll let you know if I'll be able to get it..

If the path inclusion and/or installation of stk lib into the OS path
(/usr/lib/ or /usr/local/lib) does not fix it, try the following:

1) compile flext WITHOUT stk
2) compile stk
3) try compiling munger

Best wishes,

Ico


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

Re: [PD] ANN: munger1~ port (from the Percolate library)

[Ivica Ico Bukvic]

> You know, at least on OS X, stk doesn't have a way to install itself
> so I had to guess which files were generated/needed (install.sh is
> blank).  I ended up copying the .a files (these were generated when I
> followed the instructions to build "a library of objects" by running
> make from stk's source dir) to my /usr/local/lib/stk folder and the .h
> files to /usr/local/include folder.  I'm pretty sure this is right but
> maybe I am missing something else here.  Anyway both of those should
> be in my path, I was getting different errors when they weren't.
> 
> We're going to drive you crazy over software you didn't write, Ico! :)

Impossible to drive an already crazy man crazy ;-)

I think your problem is that your .a files should *not* go into a subfolder
but directly into the /usr/local/lib folder.

Now that I also thought more about it, I think you do need to compile flext
against stk, or otherwise munger1~ won't compile since it references flstk.h
not Stk.h in its source.

Either way, aforesaid solution should fix this.

BTW, if anyone builds a binary for Win/PD, Mac/PD, or MacPPC/Max, please
forward them to me so that I can include them in the distribution.

Best wishes,

Ico



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

Re: [PD] ANN: munger1~ port (from the Percolate library)

[Ivica Ico Bukvic]

> Nope - still same error.  Thanks for the try though!  I think Thomas
> should be pondering this one soon.
> 

All right, you'll then have to be patient until I get back home tonight to
see exactly what I did to make this bugger compile on my MBP.

Best wishes,

Ico


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

Re: [PD] ANN: munger1~ port (from the Percolate library)

[Ivica Ico Bukvic]

> Nope - still same error.  Thanks for the try though!  I think Thomas
> should be pondering this one soon.
> 
> Kevin

Just checked it on my OSX machine and what I've done is as follows:

1) installed stk (regularly)
2) installed flext with STK enabled in the config.txt file inside the flext
folder, so that it points in the right direction
3) my libs are stored in /usr/local/lib (including libstk.a)
4) compiled munger~ with -lstk and it worked fine

Specific line shown during compile time has -lstk -lflext-max_t at the end
of the g++ call. The same call also has -L/usr/local/lib (not sure where
that one comes from, though--could be flext stuff).

FWIW, I also got an e-mail from Thomas Grill (author of flext) suggesting
that some changes have been made as far as OSX and Linux build of flext is
concerned which now allows for better integration with Stk and SndObj. I am
not sure what are the details surrounding this announcement, but this may
help resolve your problem.

Best wishes,

Ico


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

[PD] lowering gem camera capture CPU overhead

[Ivica Ico Bukvic]

Hi all,

I've been trying to shave off precious cycles off the FW camera input
capture. The problem is that vanilla capture of a FW camera feed (NTSC)
already introduces 50+% of CPU overhead on an AMD64 3000+. I have
experimented with lowered gem frame value, but anything below 20 seems to
jagged.

So, here are the questions:

What is the cause of such a high capture overhead?

Is there a way to minimize such overhead beyond just optimizing code for sse
and other similar methods, plus the aforesaid frame option for the gem
object?

Many thanks!

Best wishes,

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

Re: [PD] munger1~ binary for ppc

[Ivica Ico Bukvic]

Excellent work Kevin!

Actually we have another, more cleaned-up version of the code (see
attached), so if you could build that one also and then forward me the
binary, then I'll include it in the next release. FWIW, there is no
"behavioral" difference for the object but it has a cleaner implementation
of some of the routines and therefore it is theoretically more stable (even
though I have yet to experience any instabilities of the previous
implementation). Simply replace the old cpp file with this one.

Regarding the messy help file, I agree. But that's why I said in the first
place that this is the "Swiss-Army-knife" of granular synthesis ;-)

Ico

> -Original Message-
> From: Kevin McCoy [mailto:[EMAIL PROTECTED]
> Sent: Saturday, March 24, 2007 11:55 AM
> To: PD-list@iem.at; Ivica Ico Bukvic; Thomas Grill
> Subject: munger1~ binary for ppc
> 
> Hello all,
> 
> I finally got compilation of munger~ to work under OS X 10.4 on an
> iMac G5 against pd 0.39-2.  I've attached the binary in another email
> to Ico, and if I recall correctly he said he would start to include it
> with the munger source.  Of course you can email me for it as well.
> 
> Thomas and Ico, what I needed to do was copy the libstk.a file to my
> lib... I did not know about this file because STK's documentation says
> nothing about what it produces when you compile it, much to the
> frustration of beginners like myself!!  When I read Thomas' new and
> improved flext documentation (very easy to understand) I knew what
> needed to be done, and everything went very smoothly!
> 
> Ico, thanks for all your work in porting this, it sounds *wonderful*
> and I am going to get started today on making a GOP abstraction to
> control it.  This has been my "most-wanted-external" for a while now.
> The help patch, as was mentioned, is... well... dense and
> intimidating, but still usable.  Maybe we can work together on a
> simplified version if you are interested.
> 
> Damn I'm excited,
> Kevin
> 
> --
> 
> 
> 
> http://pocketkm.blogspot.com
/*
munger1~ (1.00 release)
a realtime multichannel granulator

a flext (cross-platform PD & Max/MSP) port of
the munger~ object from the PeRColate library (0.9 beta5)
http://www.music.columbia.edu/PeRColate/

Original PeRColate library by:

Dan Trueman http://www.music.princeton.edu/~dan/
R. Luke DuBois's http://www.lukedubois.com/

Flext port and additions by:
Ivica Ico Bukvic http://ico.bukvic.net
Ji-Sun Kim [EMAIL PROTECTED]
http://disis.music.vt.edu
http://www.cctad.vt.edu

Released under GPL license
(whichever is the latest version--as of this release, version 2)
For more info on the GPL license please visit:
http://www.gnu.org/copyleft/gpl.html

Changelog:

3-3-2007 Ji-Sun
*Initial flext port
*Add Verbose message on the leftmost inlet

3-4-2007 Ico
*Redesigned verbose mode (3 modes, 0 off, 1 critical (default), 2 full)
*Added ability to name instances and thus associate post messages with specific 
instances
*Fixed bug in grate_var distribution
*Additional error and warning messages
*More transparent compiler check (for random() discrepancy)
*Increased maximum number of voices to 200 (that about chokes an AMD64 3000+)

3-6-2007 Ico
*Began implementing 0.9beta6 features (buffer, oneshot, note, stk)
*We should implement association with external buffer via another message in 
the first buffer (i.e. setextbuffer 0 or name)

3-9-2007 Ico
*Finished porting 0.9beta6 (works on Linux, needs to be tested on OSX and Win32 
using Max/MSP)
*Added documentation for spatialize
*fixed bugs with multichannel diffusion
*fixed buffer crash bug (may need to test robustness of dissappearing 
buffers--it appears that Pd will crash no matter what if you
 connect to external buffer and then delete it in the middle of munger1~ trying 
to access it. Max/MSP appears to have some kind of implementation
 inside flext for this. May need to check more, but then again, who will ever 
want to delete buffers in the middle of performance?
*added discretepan option where each grain is sent only to one speaker
*tons of little bugfixes

3-10-07 Ji-Sun
*Set up proper MSVC compile environment
*Fixed oneshot MSVC bug

3-11-2007 Ico
*Further tests on MSVC Max/MSP
*Couple more bug fixes
*Are we done yet?

3-12-2007 Ico
*More bug fixes for cross-platform compatibility
*Cleaned-up float/long/int input parsing
*Added verbose 3 for calculating number of grains/second
*increased NUMVOICES to 500
*increased max channels to 24
*Fixed documentation
*/

#include 
#include 
#include 
#include 
#include 
#include 

#if !defined(FLEXT_VERSION) || (FLEXT_VERSION < 400)
#error You need at least flext version 0.4.0 with STK support
#endif

//MSVC doesn't know random(), while GCC's (at least on Linux) has rand() limit 
much higher
#ifndef __GNUC__
#define RAN

Re: [PD] munger1~ binary for ppc

[Ivica Ico Bukvic]

I'll look into this asap.

Thanks for the update!

Ico

> -Original Message-
> From: Kevin McCoy [mailto:[EMAIL PROTECTED]
> Sent: Saturday, March 24, 2007 3:33 PM
> To: Ivica Ico Bukvic; PD-list@iem.at
> Subject: Re: munger1~ binary for ppc
> 
> Ico,
> 
> This one won't build for me... I get the following output:
> 
> klangisch:/users/kmccoy/desktop/munger1~/source kmccoy$ sudo bash
> /volumes/audiowork/pdcvs/pure-data/externals/grill/flext/build.sh pd
> gcc
> make -f /volumes/audiowork/pdcvs/pure-
> data/externals/grill/flext/buildsys/gnumake-sub.mak
> PLATFORM=mac RTSYS=pd COMPILER=gcc
> BUILDPATH=/volumes/audiowork/pdcvs/pure-
> data/externals/grill/flext/buildsys/
> PKGINFO=package.txt BUILDCLASS=ext TARGETMODE=release TARGETTYPE=multi
> THREADED=1 _build_
> /volumes/audiowork/pdcvs/pure-
> data/externals/grill/flext/buildsys/mac/gnumake-gcc-targets.inc:22:
> warning: overriding commands for target `pd-darwin/release-multi'
> /volumes/audiowork/pdcvs/pure-
> data/externals/grill/flext/buildsys/mac/gnumake-gcc-targets.inc:18:
> warning: ignoring old commands for target `pd-darwin/release-multi'
> mkdir -p ./
> g++ -c -ffast-math -Os -ftree-vectorize  -arch ppc -maltivec -faltivec
>  -mtune=G4 -DNDEBUG -DFLEXT_THREADS -DFLEXT_SYS=2 -DPD -I
> pd-darwin/release-multi -I/usr/local/include/stk
> -I/usr/local/include/flext -I/Users/kmccoy/Desktop/pd-0.39-2/src
> -I/usr/local/include -I/usr/local/include/sndobj
> -I/usr/local/include/flext munger1~.cpp -o
> pd-darwin/release-multi/munger1~.opp_ppc
> munger1~.cpp: In member function 'void munger1::munger_alloc()':
> munger1~.cpp:1397: error: expression in new-declarator must have
> integral or enumeration type
> make[1]: *** [pd-darwin/release-multi/munger1~.opp_ppc] Error 1
> make: *** [build-release-multi] Error 2
> 
> __
> 
> Let me know what you think,
> Kevin
> 
> 
> On 3/24/07, Ivica Ico Bukvic <[EMAIL PROTECTED]> wrote:
> > Excellent work Kevin!
> >
> > Actually we have another, more cleaned-up version of the code (see
> > attached), so if you could build that one also and then forward me the
> > binary, then I'll include it in the next release. FWIW, there is no
> > "behavioral" difference for the object but it has a cleaner
> implementation
> > of some of the routines and therefore it is theoretically more stable
> (even
> > though I have yet to experience any instabilities of the previous
> > implementation). Simply replace the old cpp file with this one.
> >
> > Regarding the messy help file, I agree. But that's why I said in the
> first
> > place that this is the "Swiss-Army-knife" of granular synthesis ;-)
> >
> > Ico
> >
> > > -Original Message-
> > > From: Kevin McCoy [mailto:[EMAIL PROTECTED]
> > > Sent: Saturday, March 24, 2007 11:55 AM
> > > To: PD-list@iem.at; Ivica Ico Bukvic; Thomas Grill
> > > Subject: munger1~ binary for ppc
> > >
> > > Hello all,
> > >
> > > I finally got compilation of munger~ to work under OS X 10.4 on an
> > > iMac G5 against pd 0.39-2.  I've attached the binary in another email
> > > to Ico, and if I recall correctly he said he would start to include it
> > > with the munger source.  Of course you can email me for it as well.
> > >
> > > Thomas and Ico, what I needed to do was copy the libstk.a file to my
> > > lib... I did not know about this file because STK's documentation says
> > > nothing about what it produces when you compile it, much to the
> > > frustration of beginners like myself!!  When I read Thomas' new and
> > > improved flext documentation (very easy to understand) I knew what
> > > needed to be done, and everything went very smoothly!
> > >
> > > Ico, thanks for all your work in porting this, it sounds *wonderful*
> > > and I am going to get started today on making a GOP abstraction to
> > > control it.  This has been my "most-wanted-external" for a while now.
> > > The help patch, as was mentioned, is... well... dense and
> > > intimidating, but still usable.  Maybe we can work together on a
> > > simplified version if you are interested.
> > >
> > > Damn I'm excited,
> > > Kevin
> > >
> > > --
> > >
> > >
> > > 
> > > http://pocketkm.blogspot.com
> >
> >
> 
> 
> --
> 
> 
> 
> http://pocketkm.blogspot.com


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

Re: [PD] ANN: munger1~ port (from the Percolate library)

[Ivica Ico Bukvic]

> The only link I can find to download the source ( http://www.akustische-
> kunst.de/puredata/percolate.html ) is down right now.  Anyone know why, or
> if I can get the source elsewhere? 

Source for PeRColate or munger? Munger link is provided below. I downloaded
the source of the old port from the CCRMA src rpm. That one is heavily
outdated however. If you are planning on doing a port, I would suggest
contacting Dan Trueman directly and/or downloading latest OSX build which
includes source.

http://ico.bukvic.net/Max/munger1~_1.0.0.tar.gz

Best wishes,

Ico


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

Re: [PD] ANN: munger1~ port (from the Percolate library)

[Ivica Ico Bukvic]

Almost there. Fixed a ton of bugs this weekend plus made maxvoices modular.
Please stand by for updated documentation file.

Best wishes,

Ico

> -Original Message-
> From: Kevin McCoy [mailto:[EMAIL PROTECTED]
> Sent: Monday, April 02, 2007 11:18 AM
> To: Ivica Ico Bukvic; PD-list@iem.at
> Subject: Re: [PD] ANN: munger1~ port (from the Percolate library)
> 
> BTW Ico, did you ever get a chance to look at the code and see why it
> wouldn't compile the newest version for me?  I would still be happy to
> provide you with the binary if we can get it working :)
> 
> Kevin
> 
> On 4/2/07, Ivica Ico Bukvic <[EMAIL PROTECTED]> wrote:
> > > The only link I can find to download the source (
> http://www.akustische-
> > > kunst.de/puredata/percolate.html ) is down right now. Anyone know why,
> or
> > > if I can get the source elsewhere?
> >
> > Source for PeRColate or munger? Munger link is provided below. I
> downloaded
> > the source of the old port from the CCRMA src rpm. That one is heavily
> > outdated however. If you are planning on doing a port, I would suggest
> > contacting Dan Trueman directly and/or downloading latest OSX build
> which
> > includes source.
> >
> > http://ico.bukvic.net/Max/munger1~_1.0.0.tar.gz
> >
> > Best wishes,
> >
> > Ico
> >
> >
> > ___
> > PD-list@iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
> >
> 
> 
> --
> 
> 
> 
> http://pocketkm.blogspot.com


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

[PD] webcam recommendations which work in Linux

[Ivica Ico Bukvic]

Hi all,

I've seen a lot of discussion recently on the list regarding which webcam to
use but none of the recommendations seem feasible. They are either
discontinued hard-to-find products or they simply don't work. For this
reason, I was wondering if anyone has a recommendation which webcam to get
for Linux if I want a balance between fps, resolution, and stability. I also
read about IP cameras but am not sure if these can be interfaces with gem.

Any help is most appreciated!

Ivica Ico Bukvic, D.M.A.
Composition, Music Technology, CCTAD, CHCI
Virginia Tech
Dept. of Music - 0240
Blacksburg, VA 24061
(540) 231-1137
(540) 231-5034 (fax)
[EMAIL PROTECTED]
http://www.music.vt.edu/people/faculty/bukvic/




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

Re: [PD] webcam recommendations which work in Linux

[Ivica Ico Bukvic]

Thanks for the reply. Regarding fw solutions, I do have ADVC but that one
eats my CPU like crazy. Are there any fw solutions which are less CPU
greedy? Also regarding wireless/ip cameras, can those be interfaced with PD?

Ico

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
> Alexandre Quessy
> Sent: Thursday, April 19, 2007 11:28 PM
> To: Ivica Ico Bukvic
> Cc: PD-list@iem.at; [EMAIL PROTECTED]
> Subject: Re: [PD] webcam recommendations which work in Linux
> 
> Hi,
> I had a good experience with the Logitech QuickCam for Notebooks
> Deluxe. Logitech QuickCam in general are a good suggestion. I had
> success with firewire as well, which allows more flexibility, of
> course.
> 
> a
> 
> 2007/4/19, Ivica Ico Bukvic <[EMAIL PROTECTED]>:
> > Hi all,
> >
> > I've seen a lot of discussion recently on the list regarding which
> webcam to
> > use but none of the recommendations seem feasible. They are either
> > discontinued hard-to-find products or they simply don't work. For this
> > reason, I was wondering if anyone has a recommendation which webcam to
> get
> > for Linux if I want a balance between fps, resolution, and stability. I
> also
> > read about IP cameras but am not sure if these can be interfaces with
> gem.
> >
> > Any help is most appreciated!
> >
> > Ivica Ico Bukvic, D.M.A.
> > Composition, Music Technology, CCTAD, CHCI
> > Virginia Tech
> > Dept. of Music - 0240
> > Blacksburg, VA 24061
> > (540) 231-1137
> > (540) 231-5034 (fax)
> > [EMAIL PROTECTED]
> > http://www.music.vt.edu/people/faculty/bukvic/
> >
> >
> >
> >
> > ___
> > PD-list@iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
> >
> 
> 
> --
> Alexandre Quessy
> http://alexandre.quessy.net
> http://www.puredata.info/Members/aalex


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

Re: [PD] webcam recommendations which work in Linux

[Ivica Ico Bukvic]

> I have two Logitech Quickcam IM working fine @25fps in 640x480 connected 
> at the same time with Gem on Debian, driver is called spca5xx  from 
> http://mxhaard.free.fr , loaded as a module thanks to the module-
> assistant.

> About IP cameras: 
> the Axis PTZ 214 has a built-in linux server streaming out both in RTSP & 
> http, Photo-jpeg or MPEG4 streams. Lots of docs available. I havent 
> streamed into PD yet , but should be feasable if Gem/pdp compiled with the

> needed libs.

Thanks for the info! BTW, if anyone has any info on how to interface IP
cameras, I would love to hear more about it.

Best wishes,

Ico



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

[PD] ANN: munger1~ 1.1.0 released

[Ivica Ico Bukvic]

Hi all,

For impatient, download at: http://ico.bukvic.net/Max/munger1~_latest.tar.gz
(796KB, includes source, Linux-Pd-i386, Mac-Max-i386, and Win32-Max-i386
binaries, and 2 pounds of /dev/null)

If you build a binary for other platform/software combos please forward them
to me so that I can include them in the tarball.


CHANGELOG
=
Memory allocation fix
Code clean-up
Fix Pd crash when buffer forcefully deleted
Updated documentation
New option to dynamically alter max voices
Fixed bucketload of memory leaks


OVERVIEW

munger1~ (May 2, 2007 1.1.0 release)
a realtime multichannel granulator
a.k.a. the swiss-army-knife of realtime granular synthesis

a flext (cross-platform PD & Max/MSP) port of
the munger~ object from the PeRColate library (0.9 beta5)
http://www.music.columbia.edu/PeRColate/

Original PeRColate library by:

Dan Trueman http://www.music.princeton.edu/~dan/
R. Luke DuBois's http://www.lukedubois.com/

Flext port and additions by:
Ivica Ico Bukvic http://ico.bukvic.net
Ji-Sun Kim [EMAIL PROTECTED]
http://www.music.vt.edu 
http://www.cctad.vt.edu

Released under GPL license
(whichever is the latest version--as of this release, version 2)
For more info on the GPL license please visit:
http://www.gnu.org/copyleft/gpl.html

Enjoy!


Best wishes,

Ivica Ico Bukvic, D.M.A.
Composition, Music Technology, CCTAD, CHCI
Virginia Tech
Dept. of Music - 0240
Blacksburg, VA 24061
(540) 231-1137
(540) 231-5034 (fax)
[EMAIL PROTECTED]
http://www.music.vt.edu/people/faculty/bukvic/



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

[PD] ANN: munger1~ 1.2.0 released

[Ivica Ico Bukvic]

Hi all,

For impatient, download from usual place:
http://ico.bukvic.net/Max/munger1~_latest.tar.gz (~1MB, now includes source,
Linux-Pd-i386, Mac-Max-UB, and Win32-Max-i386 binaries, and my feeble
attempt at improved documentation)

If you build a binary for other platform/software combos please forward them
to me so that I can include them in the tarball. Still looking for Pd-OSX
and Pd-Win32 versions...


CHANGELOG
=
Destructor clean-up
Resolved ADSR/MSVC mess
More documentation improvements
Max channels set to 64 and max voices to 1000 (for the sake of setting some
kind of a limit, otherwise the thing is now 100% dynamically allocated)
Memory allocation is now fully optimized and modular
Added OSX UB (please test it on PPC)


OVERVIEW

munger1~ (May 2, 2007 1.2.0 release)
a realtime multichannel granulator
a.k.a. the swiss-army-knife of realtime granular synthesis

a flext (cross-platform PD & Max/MSP) port of
the munger~ object from the PeRColate library (0.9 beta5)
http://www.music.columbia.edu/PeRColate/

Original PeRColate library by:

Dan Trueman http://www.music.princeton.edu/~dan/
R. Luke DuBois's http://www.lukedubois.com/

Flext port and additions by:
Ivica Ico Bukvic http://ico.bukvic.net
Ji-Sun Kim [EMAIL PROTECTED]
http://www.music.vt.edu 
http://www.cctad.vt.edu

Released under GPL license
(whichever is the latest version--as of this release, version 2)
For more info on the GPL license please visit:
http://www.gnu.org/copyleft/gpl.html

Enjoy!


Best wishes,

Ivica Ico Bukvic, D.M.A.
Composition, Music Technology, CCTAD, CHCI
Virginia Tech
Dept. of Music - 0240
Blacksburg, VA 24061
(540) 231-1137
(540) 231-5034 (fax)
[EMAIL PROTECTED]
http://www.music.vt.edu/people/faculty/bukvic/



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

[PD] ANN: munger1~ 1.3.0 released

[Ivica Ico Bukvic]

First of all, apologies for wasting everyone's bandwidth with the last
release which was/is for most intents and purposes broken. This new release
dubbed "I hate MSVC" ought to [hopefully] solve lingering problems.

Download from usual place: http://ico.bukvic.net/Max/munger1~_latest.tar.gz
(~400KB, includes source, Linux-Pd-i386, Mac-Max-UB, and Win32-Max-i386
binaries)

CHANGELOG
=
More MSVC+flext oddities--forced to use static array of ADSRs
Memory leakage finally fixed?
Tons of tiny bug-fixes
Added versioning system
Built against latest flext CVS checkout
Fixed OSX UB (please test)

Best wishes,

Ivica Ico Bukvic, D.M.A.
Composition, Music Technology, CCTAD, CHCI
Virginia Tech
Dept. of Music - 0240
Blacksburg, VA 24061
(540) 231-1137
(540) 231-5034 (fax)
[EMAIL PROTECTED]
http://www.music.vt.edu/people/faculty/bukvic/
http://ico.bukvic.net



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

[PD] ANN: munger1~ 1.3.1 released

[Ivica Ico Bukvic]

Download from usual place: http://ico.bukvic.net/Max/munger1~_latest.tar.gz
or http://ico.bukvic.net/Max/munger1~_latest.zip (~370KB, includes source,
Linux-Pd-i386, Mac-Max-UB, and Win32-Max-i386 binaries)

CHANGELOG
=
1.3.1 (May 15 2007)
Fixed Windows issue with modular ADSR instances
Build fixes for Linux
Are we done yet?
Best wishes,

Ivica Ico Bukvic, D.M.A.
Composition, Music Technology, CCTAD, CHCI
Virginia Tech
Dept. of Music - 0240
Blacksburg, VA 24061
(540) 231-1137
(540) 231-5034 (fax)
[EMAIL PROTECTED]
http://www.music.vt.edu/people/faculty/bukvic/
http://ico.bukvic.net



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

[PD] ANN: RTMix 0.76 (a.k.a. "rtmix lives on")

[Ivica Ico Bukvic]

Well, it's been over 2 (3?) years since last release, but rtmix refuses to
die ;-). Thanks solely to Robin Gareus and his heroic work in making rtmix
gcc4 compliant, I am releasing rtmix version 0.76. Apart from compile error
fixes (courtesy of Robin), there have been a few cosmetic tweaks, but most
notably, the source is now released under a 100% GPL-compliant license. That
being said, the code is still a dirty hack, the internal event cue
occasionally still misbehaves (albeit only in very complex situations), and
unfortunately native alsa seq is still MIA (uses old unix dev access). OTOH,
the thing does work as advertised, has been used, and continues to be used
in my works without a hitch. Apart from oss midi, rtmix supports networking,
OSC, and other goodness making it rather practical for on-screen
coordination as well as interaction between performer(s) and computer.

For more info on what really rtmix is please consult the HTML documentation
included with the tarball (or see online documentation info below). The
tarball (5MB) comes with source, documentation (some statements in it are
likely a bit outdated, so please take those parts with a grain of salt),
tutorials, and precompiled binary on Ubuntu 6.10 (i686, qt3, gcc), so if you
have these a simple "make install" should do it (installs in
/usr/local/rtmix and binary in /usr/local/bin). For a "simon" tutorial with
sounds you will also need sounds zipfile (11MB-ish) which are downloadable
from the same folder (just browse the folder).

To download latest RTMix click here:

http://ico.bukvic.net/Linux/RTMix/rtmix-latest.tar.gz 

Online documentation:

http://ico.bukvic.net/Linux/RTMix/RTMix-docs/

Complaints to: /dev/null

Future roadmap:
Rtmix in its current state is a project in a need of a total rewrite. This
is primarily due to the fact that despite the fact rtmix appears to do the
job in 99.9% of instances, the code is an ugly hack which makes its
maintenance and perhaps more importantly expandability exponentially
difficult. That being said, I am looking forward to one of the upcoming
summers when I will dig into the code once again and rebuild the darn thing
from the ground up the way it was meant to be all along. Until then, this
version should prove an adequate substitute.

Enjoy!

Ivica Ico Bukvic, D.M.A.
Composition, Music Technology, CCTAD, CHCI
Virginia Tech
Dept. of Music - 0240
Blacksburg, VA 24061
(540) 231-1137
(540) 231-5034 (fax)
[EMAIL PROTECTED]
http://www.music.vt.edu/people/faculty/bukvic/
http://ico.bukvic.net




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

Re: [PD] ANN: RTMix 0.76 (a.k.a. "rtmix lives on")

[Ivica Ico Bukvic]

Just realized that there was already a 0.76 release back in 2003... DOH!
Let's then call this one 0.76b ;-)

Ico



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

[PD] [PD-announce] L2Ork North Carolina Mini-Tour

[Ivica Ico Bukvic]

Please pardon the cross-posting as well as the belated nature of the message.

L2Ork Virginia Tech's Linux Laptop Orchestra is back on tour Sept. 19-21st with 
performances at Duke University, WSSU, and UNCG as part of the New Music 
Festival (http://uncgnmf2010.org/).

For additional info on performances:
http://l2ork.music.vt.edu/main/?page_id=21

About L2Ork:
http://l2ork.music.vt.edu/main/
http://l2ork.music.vt.edu/main/?page_id=5

L2Ork on Facebook:
http://www.facebook.com/group.php?gid=117918141555131

L2Ork PD resources including custom version of Pd extended and supporting 
externals (under construction):
http://l2ork.music.vt.edu/main/?page_id=56

Should you happen to have any questions, suggestions or concerns, please do not 
hesitate to contact me.

Best wishes,

Ivica Ico Bukvic, D.M.A.
Composition, Music Technology
Director, DISIS Interactive Sound & Intermedia Studio
Director, L2Ork Linux Laptop Orchestra
Assistant Co-Director, CCTAD
CHCI, CS, and Art (by courtesy)
Virginia Tech
Dept. of Music - 0240
Blacksburg, VA 24061
(540) 231-6139
(540) 231-5034 (fax)
i...@vt.edu
http://www.music.vt.edu/faculty/bukvic/



___
Pd-announce mailing list
pd-annou...@iem.at
http://lists.puredata.info/listinfo/pd-announce

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

[PD] coll alternative

[Ivica Ico Bukvic]

Does anyone have a good/practical alternative to the coll object? I've noticed 
some consistent xruns this object is causing when processing larger files 
(which seems surprising to me as operations it relies on should not be that CPU 
intensive).

Also, does anyone have any idea what might be possibly causing the xruns within 
the object itself. Could it be perhaps File I/O operations or the fact that 
dump object generates tons of operations down the pipeline (despite the fact 
that all of those are pretty benign in and of themselves, amounting mostly to 
routing and minor processing of output)?

Any thoughts would be most appreciated.

Best wishes,

Ivica Ico Bukvic, D.M.A.
Composition, Music Technology
Director, DISIS Interactive Sound & Intermedia Studio
Director, L2Ork Linux Laptop Orchestra
Assistant Co-Director, CCTAD
CHCI, CS, and Art (by courtesy)
Virginia Tech
Dept. of Music - 0240
Blacksburg, VA 24061
(540) 231-6139
(540) 231-5034 (fax)
i...@vt.edu
http://www.music.vt.edu/faculty/bukvic/


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

Re: [PD] coll alternative

[Ivica Ico Bukvic]

Many thanks for the info. BTW, what lib does msgfile belong to? Doesn't appear 
to be a part of the Pd vanilla.

Best wishes,

Ico

> -Original Message-
> From: Husk 00 [mailto:hus...@gmail.com]
> Sent: Thursday, September 23, 2010 11:10 AM
> To: Ivica Ico Bukvic
> Cc: pd-list@iem.at
> Subject: Re: [PD] coll alternative
> 
> On Thu, Sep 23, 2010 at 4:12 AM, Ivica Ico Bukvic  wrote:
> > Does anyone have a good/practical alternative to the coll object? I've
> noticed some consistent xruns this object is causing when processing
> larger files (which seems surprising to me as operations it relies on should
> not be that CPU intensive).
> 
> 
> Hi Ivica,
> take a look to msgfile object
> cheers
> husk
> 
> 
> --
> when Art become pratical
> we call it technology.
> 
> When Technology become useless
> we call it Art
> 
> www.estereotips.net


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

Re: [PD] coll alternative

[Ivica Ico Bukvic]

Many thanks!

> -Original Message-
> From: Jack [mailto:j...@rybn.org]
> Sent: Thursday, September 23, 2010 12:00 PM
> To: Ivica Ico Bukvic
> Cc: 'Husk 00'; pd-list@iem.at
> Subject: Re: [PD] coll alternative
> 
> Zexy.
> ++
> 
> Jack
> 
> 
> 
> Le jeudi 23 septembre 2010 à 11:51 -0400, Ivica Ico Bukvic a écrit :
> > Many thanks for the info. BTW, what lib does msgfile belong to? Doesn't
> appear to be a part of the Pd vanilla.
> >
> > Best wishes,
> >
> > Ico
> >
> > > -Original Message-
> > > From: Husk 00 [mailto:hus...@gmail.com]
> > > Sent: Thursday, September 23, 2010 11:10 AM
> > > To: Ivica Ico Bukvic
> > > Cc: pd-list@iem.at
> > > Subject: Re: [PD] coll alternative
> > >
> > > On Thu, Sep 23, 2010 at 4:12 AM, Ivica Ico Bukvic  wrote:
> > > > Does anyone have a good/practical alternative to the coll object?
> I've
> > > noticed some consistent xruns this object is causing when processing
> > > larger files (which seems surprising to me as operations it relies on
> should
> > > not be that CPU intensive).
> > >
> > >
> > > Hi Ivica,
> > > take a look to msgfile object
> > > cheers
> > > husk
> > >
> > >
> > > --
> > > when Art become pratical
> > > we call it technology.
> > >
> > > When Technology become useless
> > > we call it Art
> > >
> > > www.estereotips.net
> >
> >
> > ___
> > Pd-list@iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list



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

[PD] xruns in coll and msgfile and a question about the threaded external design

[Ivica Ico Bukvic]

So, I looked further into msgfile and coll and found out whenever they try to 
do file i/o on files with moderate number of lines (or greater), e.g. 500+ 
lines, there is a guaranteed xrun when Pd is running with a small internal 
audio buffer (FWIW, all this has been observed on an atom computer where likely 
high cpu load threshold is more easily tripped and thus these problems are 
perhaps more apparent). Consequently this makes me wonder if it may be a good 
idea to adapt one of these objects so that they do file i/o in a separate 
thread?

This brings me to my second question. Mrpeach tcpserver with recently submitted 
patches wraps broadcast call into a separate thread which is terminated as soon 
as a particular task is complete. One would think that this kind of a design 
should be better in terms of preventing audio xruns. Yet, in practice I've 
discovered that it still causes xruns fairly regularly, particularly when the 
computer is under load. OTOH, the disis_wiimote object developed as part of the 
L2Ork project which maintains a persistent secondary thread for triggering 
rumble and LED toggle calls to the wiimote never trips an xrun, no matter what 
the workload.

By now you are probably wondering what is my question. Actually there are 
several:

1) If tcpserver's "spawn a secondary thread, execute, terminate secondary 
thread" is causing xruns but disis_wiimote's persistent secondary thread with 
mutex does not, does this mean that spawning threads is so taxing on the 
computer so as to cause the aforesaid xruns thus defeating the very advantage 
one is trying to generate by spawning them?

2) If answer to #1 is yes, is this because tcpserver's thread is one that 
detaches from the main thread?

3) if answer #2 is yes, is there anything one can do to lower the overhead of 
this breakaway thread?

4) could one ostensibly use persistent thread model from disis_wiimote on coll 
and/or msgfile in order to abate file i/o xruns?

5) if answer to #4 is yes, could the secondary thread call clock_delay()to 
provide a bang-on-read-complete (as the coll does) even though it is 
effectively running independently from the main thread without causing a major 
ruckus inside Pd's internal interrupt/clock that deals with audio and gui 
updates?

Any help is most appreciated.

Ivica Ico Bukvic, D.M.A.
Composition, Music Technology
Director, DISIS Interactive Sound & Intermedia Studio
Director, L2Ork Linux Laptop Orchestra
Assistant Co-Director, CCTAD
CHCI, CS, and Art (by courtesy)
Virginia Tech
Dept. of Music - 0240
Blacksburg, VA 24061
(540) 231-6139
(540) 231-5034 (fax)
i...@vt.edu
http://www.music.vt.edu/faculty/bukvic/


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

[PD] xrun-free file i/o using the coll external (SOLVED)

[Ivica Ico Bukvic]

In hope to answer some of the questions I presented on the pd-list the
other day, attached is the patch (diff -u against pd-extended svn
0.42.5) that converts miXed/cyclone/coll.c object into a threaded
version which in turn does not trigger xruns every time one tries to
open or save a file at runtime. This is particularly apparent when
opening/closing large files using low latency audio buffers. This
problem is also apparent in other similar objects (e.g. msgfile) and
should be ostensibly solvable using the same principle.

Additional lessons I learned from this exercise and am sharing them here
in hope others may benefit from them as well are as follows:

1) Spawning a secondary thread within an external (detached or not)
should in principle never result in an xrun, except in the coll object I
discovered that always the first thread creation did result in an xrun
which is why the code also does a bogus thread immediately following the
creation time using clock_delay. I am not sure whether this is
atom-CPU-specific or more widespread and/or whether this has to do with
the way PD is designed. Any thoughts are most appreciated here.

2) Triggering clock_delay from a separate thread works fine and should
be always used (rather than dealing with the outlet traffic directly) to
prevent out-of-sync gui operations which may result in gui
freezing/crashing.

Cheers!

Ico

--- coll.c.orig	2010-09-24 11:16:17.0 -0400
+++ coll.c	2010-09-25 11:23:27.0 -0400
@@ -9,6 +9,8 @@
 #include "common/loud.h"
 #include "hammer/file.h"
 
+#include 
+
 /* LATER profile for the bottlenecks of insertion and sorting */
 /* LATER make sure that ``reentrancy protection hack'' is really working... */
 
@@ -60,11 +62,53 @@
 t_outlet  *x_filebangout;
 t_outlet  *x_dumpbangout;
 struct _coll  *x_next;
+
+	//for thread-unsafe file i/o operations
+	//added by Ivica Ico Bukvic  9-24-2010
+	//http://disis.music.vt.edu http://l2ork.music.vt.edu
+	t_clock *x_clock;
+	t_clock *x_init; /* for initializing first dummy thread */
+	pthread_t 		unsafer_t; /* read */
+	pthread_t		unsafew_t; /* write */
+	pthread_attr_t	unsafe_attr;
+
+	int busy; /* used as a simple one-way communication between the threads */
 } t_coll;
 
+typedef struct _threadedFunctionParams
+{
+	t_coll *x;
+	t_collcommon *cc;
+	t_symbol *fn;
+	t_canvas *cv;
+} t_threadedFunctionParams;
+
 static t_class *coll_class;
 static t_class *collcommon_class;
 
+//pre-declare threaded functions
+static void *coll_threadedread(void *ptr);
+static void *coll_threadedwrite(void *ptr);
+
+void coll_tick(t_coll *x, int n)
+{
+outlet_bang(x->x_filebangout);
+}
+
+void coll_dummy_init(t_coll *x)
+{
+	//first thread creation always trips an xrun (no idea why)
+	//so let's create a bogus one that will exit immediately since s is NULL
+	t_threadedFunctionParams rPars;
+	rPars.x = x;
+	rPars.cc = NULL;
+	rPars.fn = NULL;
+	rPars.cv = NULL;
+	pthread_create( &x->unsafer_t, &x->unsafe_attr, (void *) &coll_threadedread, (void *) &rPars);
+}
+
+
+
 static t_collelem *collelem_new(int ac, t_atom *av, int *np, t_symbol *s)
 {
 t_collelem *ep = (t_collelem *)getbytes(sizeof(*ep));
@@ -201,6 +245,8 @@
 }
 }
 
+
+
 /* atomic collcommon modifiers:  clearall, remove, replace,
putbefore, putafter, swaplinks, swapkeys, changesymkey, renumber, sort */
 
@@ -582,6 +628,78 @@
 return (collcommon_fromatoms(cc, binbuf_getnatom(bb), binbuf_getvec(bb)));
 }
 
+static void *coll_threadedread(void *ptr)
+{	
+	t_threadedFunctionParams *rPars = (t_threadedFunctionParams*)ptr;
+	t_coll *x = rPars->x;
+	t_collcommon *cc = rPars->cc;
+	t_symbol *fn = rPars->fn;
+	t_canvas *cv = rPars->cv;
+
+if (!cc) /* safety */
+		return NULL;
+
+t_binbuf *bb;
+char buf[MAXPDSTRING];
+if (!fn && !(fn = cc->c_filename))  /* !fn: 'readagain' */
+		return NULL;
+/* FIXME use open_via_path() */
+if (cv || (cv = cc->c_lastcanvas))  /* !cv: 'read' w/o arg, 'readagain' */
+	canvas_makefilename(cv, fn->s_name, buf, MAXPDSTRING);
+else
+{
+	strncpy(buf, fn->s_name, MAXPDSTRING);
+	buf[MAXPDSTRING-1] = 0;
+}
+if (!cc->c_refs)
+{
+	/* loading during object creation --
+	   avoid binbuf_read()'s complaints, LATER rethink */
+	FILE *fp;
+	char fname[MAXPDSTRING];
+	sys_bashfilename(buf, fname);
+	if (!(fp = fopen(fname, "r")))
+	{
+	loud_warning(&coll_class, 0, "no coll file '%s'", fname);
+	return NULL;
+	}
+	fclose(fp);
+}
+bb = binbuf_new();
+if (binbuf_read(bb, buf, "", 0))
+	loud_error(0, "coll: error reading text file '%s'", fn->s_name);
+else
+{
+	int nlines = collcommon_frombinbuf(cc, bb);
+	if (nlines > 0)
+	{
+	t_coll *x;
+	/* LATER consider making this more robust */
+	for (x = cc->c_refs; x; x =

Re: [PD] xrun-free file i/o using the coll external (SOLVED)

[Ivica Ico Bukvic]

Oops, please use the attached patch instead.

Best wishes,

Ico

On Sat, 2010-09-25 at 12:36 -0400, Ivica Ico Bukvic wrote:
> In hope to answer some of the questions I presented on the pd-list the
> other day, attached is the patch (diff -u against pd-extended svn
> 0.42.5) that converts miXed/cyclone/coll.c object into a threaded
> version which in turn does not trigger xruns every time one tries to
> open or save a file at runtime. This is particularly apparent when
> opening/closing large files using low latency audio buffers. This
> problem is also apparent in other similar objects (e.g. msgfile) and
> should be ostensibly solvable using the same principle.
> 
> Additional lessons I learned from this exercise and am sharing them here
> in hope others may benefit from them as well are as follows:
> 
> 1) Spawning a secondary thread within an external (detached or not)
> should in principle never result in an xrun, except in the coll object I
> discovered that always the first thread creation did result in an xrun
> which is why the code also does a bogus thread immediately following the
> creation time using clock_delay. I am not sure whether this is
> atom-CPU-specific or more widespread and/or whether this has to do with
> the way PD is designed. Any thoughts are most appreciated here.
> 
> 2) Triggering clock_delay from a separate thread works fine and should
> be always used (rather than dealing with the outlet traffic directly) to
> prevent out-of-sync gui operations which may result in gui
> freezing/crashing.
> 
> Cheers!
> 
> Ico
> 

--- coll.c.orig	2010-09-24 11:16:17.0 -0400
+++ coll.c	2010-09-25 19:33:38.0 -0400
@@ -9,6 +9,8 @@
 #include "common/loud.h"
 #include "hammer/file.h"
 
+#include 
+
 /* LATER profile for the bottlenecks of insertion and sorting */
 /* LATER make sure that ``reentrancy protection hack'' is really working... */
 
@@ -60,11 +62,51 @@
 t_outlet  *x_filebangout;
     t_outlet  *x_dumpbangout;
 struct _coll  *x_next;
+
+	//for thread-unsafe file i/o operations
+	//added by Ivica Ico Bukvic  9-24-2010
+	//http://disis.music.vt.edu http://l2ork.music.vt.edu
+	t_clock *x_clock;
+	//t_clock *x_init; /* for initializing first dummy thread */
+	pthread_t 		unsafer_t; /* read */
+	pthread_t		unsafew_t; /* write */
+	pthread_attr_t	unsafe_attr;
+
+	int busy; /* used as a simple one-way communication between the threads */
 } t_coll;
 
+typedef struct _threadedFunctionParams
+{
+	t_coll *x;
+	t_collcommon *cc;
+	t_symbol *fn;
+	t_canvas *cv;
+} t_threadedFunctionParams;
+
 static t_class *coll_class;
 static t_class *collcommon_class;
 
+//pre-declare threaded functions
+static void *coll_threadedread(void *ptr);
+static void *coll_threadedwrite(void *ptr);
+
+void coll_tick(t_coll *x, int n)
+{
+outlet_bang(x->x_filebangout);
+}
+
+//void coll_dummy_init(t_coll *x)
+//{
+//	//first thread creation always trips an xrun (no idea why)
+//	//so let's create a bogus one that will exit immediately since s is NULL
+//	t_threadedFunctionParams rPars;
+//	rPars.x = x;
+//	rPars.cc = NULL;
+//	rPars.fn = NULL;
+//	rPars.cv = NULL;
+//	pthread_create( &x->unsafer_t, &x->unsafe_attr, (void *) &coll_threadedread, (void *) &rPars);
+//}
+
 static t_collelem *collelem_new(int ac, t_atom *av, int *np, t_symbol *s)
 {
 t_collelem *ep = (t_collelem *)getbytes(sizeof(*ep));
@@ -201,6 +243,8 @@
 }
 }
 
+
+
 /* atomic collcommon modifiers:  clearall, remove, replace,
putbefore, putafter, swaplinks, swapkeys, changesymkey, renumber, sort */
 
@@ -582,6 +626,78 @@
 return (collcommon_fromatoms(cc, binbuf_getnatom(bb), binbuf_getvec(bb)));
 }
 
+static void *coll_threadedread(void *ptr)
+{	
+	t_threadedFunctionParams *rPars = (t_threadedFunctionParams*)ptr;
+	t_coll *x = rPars->x;
+	t_collcommon *cc = rPars->cc;
+	t_symbol *fn = rPars->fn;
+	t_canvas *cv = rPars->cv;
+
+if (!cc) /* safety */
+		return NULL;
+
+t_binbuf *bb;
+char buf[MAXPDSTRING];
+if (!fn && !(fn = cc->c_filename))  /* !fn: 'readagain' */
+		return NULL;
+/* FIXME use open_via_path() */
+if (cv || (cv = cc->c_lastcanvas))  /* !cv: 'read' w/o arg, 'readagain' */
+	canvas_makefilename(cv, fn->s_name, buf, MAXPDSTRING);
+else
+{
+	strncpy(buf, fn->s_name, MAXPDSTRING);
+	buf[MAXPDSTRING-1] = 0;
+}
+if (!cc->c_refs)
+{
+	/* loading during object creation --
+	   avoid binbuf_read()'s complaints, LATER rethink */
+	FILE *fp;
+	char fname[MAXPDSTRING];
+	sys_bashfilename(buf, fname);
+	if (!(fp = fopen(fname, "r")))
+	{
+	loud_warning(&coll_class, 0, "no coll file '%s'", fname);
+	return NULL;
+	}
+	fclose(fp);
+}
+bb = binbuf_new();
+if (binbuf_read(bb, buf, ""

Re: [PD] xrun-free file i/o using the coll external (SOLVED)

[Ivica Ico Bukvic]

All right, third time is a charm. This time implementation uses
persistent thread and safer mutex approach, as well as cleaner code.
Spawning and detaching threads in the previous iteration has
inexplicably caused considerable tear in pd<->gui communication. If
anyone has any explanation why that would be I would greatly appreciate
your feedback.

Best wishes,

Ico

On Sat, 2010-09-25 at 20:05 -0400, Ivica Ico Bukvic wrote:
> Oops, please use the attached patch instead.
> 
> Best wishes,
> 
> Ico
> 
> On Sat, 2010-09-25 at 12:36 -0400, Ivica Ico Bukvic wrote:
> > In hope to answer some of the questions I presented on the pd-list the
> > other day, attached is the patch (diff -u against pd-extended svn
> > 0.42.5) that converts miXed/cyclone/coll.c object into a threaded
> > version which in turn does not trigger xruns every time one tries to
> > open or save a file at runtime. This is particularly apparent when
> > opening/closing large files using low latency audio buffers. This
> > problem is also apparent in other similar objects (e.g. msgfile) and
> > should be ostensibly solvable using the same principle.
> > 
> > Additional lessons I learned from this exercise and am sharing them here
> > in hope others may benefit from them as well are as follows:
> > 
> > 1) Spawning a secondary thread within an external (detached or not)
> > should in principle never result in an xrun, except in the coll object I
> > discovered that always the first thread creation did result in an xrun
> > which is why the code also does a bogus thread immediately following the
> > creation time using clock_delay. I am not sure whether this is
> > atom-CPU-specific or more widespread and/or whether this has to do with
> > the way PD is designed. Any thoughts are most appreciated here.
> > 
> > 2) Triggering clock_delay from a separate thread works fine and should
> > be always used (rather than dealing with the outlet traffic directly) to
> > prevent out-of-sync gui operations which may result in gui
> > freezing/crashing.
> > 
> > Cheers!
> > 
> > Ico
> > 
> 

--- coll.c.orig	2010-09-24 11:16:17.0 -0400
+++ coll.c	2010-09-26 13:19:37.0 -0400
@@ -9,6 +9,8 @@
 #include "common/loud.h"
 #include "hammer/file.h"
 
+#include 
+
 /* LATER profile for the bottlenecks of insertion and sorting */
 /* LATER make sure that ``reentrancy protection hack'' is really working... */
 
@@ -60,11 +62,36 @@
 t_outlet  *x_filebangout;
 t_outlet  *x_dumpbangout;
 struct _coll  *x_next;
+
+	//for thread-unsafe file i/o operations
+	//added by Ivica Ico Bukvic  9-24-2010
+	//http://disis.music.vt.edu http://l2ork.music.vt.edu
+	t_clock *x_clock;
+
+	pthread_t unsafe_t;
+	pthread_mutex_t unsafe_mutex;
+	pthread_cond_t unsafe_cond;
+
+	t_symbol *x_s;
+	t_float unsafe;
+
+	//int busy;
 } t_coll;
 
+typedef struct _threadedFunctionParams
+{
+	t_coll *x;
+} t_threadedFunctionParams;
+
 static t_class *coll_class;
 static t_class *collcommon_class;
 
+void coll_tick(t_coll *x)
+{
+	//x->busy = 0;
+outlet_bang(x->x_filebangout);
+}
+
 static t_collelem *collelem_new(int ac, t_atom *av, int *np, t_symbol *s)
 {
 t_collelem *ep = (t_collelem *)getbytes(sizeof(*ep));
@@ -201,6 +228,8 @@
 }
 }
 
+
+
 /* atomic collcommon modifiers:  clearall, remove, replace,
putbefore, putafter, swaplinks, swapkeys, changesymkey, renumber, sort */
 
@@ -621,7 +650,7 @@
 	t_coll *x;
 	/* LATER consider making this more robust */
 	for (x = cc->c_refs; x; x = x->x_next)
-		outlet_bang(x->x_filebangout);
+		//outlet_bang(x->x_filebangout);
 	cc->c_lastcanvas = cv;
 	cc->c_filename = fn;
 	post("coll: finished reading %d lines from text file '%s'",
@@ -952,234 +981,264 @@
 
 static void coll_float(t_coll *x, t_float f)
 {
-t_collcommon *cc = x->x_common;
-t_collelem *ep;
-int numkey;
-if (loud_checkint((t_pd *)x, f, &numkey, &s_float) &&
-	(ep = collcommon_numkey(cc, numkey)))
-{
-	coll_keyoutput(x, ep);
-	if (!cc->c_selfmodified || (ep = collcommon_numkey(cc, numkey)))
-	coll_dooutput(x, ep->e_size, ep->e_data);
-}
+	//if (!x->busy) {
+		t_collcommon *cc = x->x_common;
+		t_collelem *ep;
+		int numkey;
+		if (loud_checkint((t_pd *)x, f, &numkey, &s_float) &&
+		(ep = collcommon_numkey(cc, numkey)))
+		{
+		coll_keyoutput(x, ep);
+		if (!cc->c_selfmodified || (ep = collcommon_numkey(cc, numkey)))
+			coll_dooutput(x, ep->e_size, ep->e_data);
+		}
+	//}
 }
 
 static void coll_symbol(t_coll *x, t_symbol *s)
 {
-t_collcommon *cc = x->x_common;
-t_collelem *ep;
-if (ep = collcommon_symkey(cc, s))
-{
-	coll_keyoutput(x, ep);
-	if (

Re: [PD] GUI speed

[Ivica Ico Bukvic]

FWIW you may want to try to simply cut pieces of the patch while it is running 
and observe the cpu load meter until it drops. That way you should be able to 
locate the problem quicker.

HTH

Ico

João Pais  wrote:

>> Well, it's not very exportable as i have modified/overwritten some
>> abstractions made by others. Baaad practice!
>> I'm trying to attach it now and i hope i works. Need pd-extended and many
>> libs from it, moonlib for sure.
>
>not much, some abstractions are missing.
>
>anyway, even with the patch not working, I can see something is  
>definitively wrong. just by opening it with audio off, I get consistent  
>50% cpu usage - which means it's using a whole processor of my dual core.  
>unless one of the missing abs is the problem, I would suggest you spend  
>some hours bug tracking.
>
>João
>
>___
>Pd-list@iem.at mailing list
>UNSUBSCRIBE and account-management -> 
>http://lists.puredata.info/listinfo/pd-list
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] xrun-free file i/o using the coll external (SOLVED)

[Ivica Ico Bukvic]

Here's the cleaned-up and hopefully final version with a couple more
improvements and bugfixes. Sorry for the barrage of sloppy patches...
--- coll.c.orig	2010-09-24 11:16:17.0 -0400
+++ coll.c	2010-09-26 16:21:40.0 -0400
@@ -9,6 +9,8 @@
 #include "common/loud.h"
 #include "hammer/file.h"
 
+#include 
+
 /* LATER profile for the bottlenecks of insertion and sorting */
 /* LATER make sure that ``reentrancy protection hack'' is really working... */
 
@@ -60,11 +62,34 @@
 t_outlet  *x_filebangout;
 t_outlet  *x_dumpbangout;
 struct _coll  *x_next;
+
+	//for thread-unsafe file i/o operations
+	//added by Ivica Ico Bukvic  9-24-2010
+	//http://disis.music.vt.edu http://l2ork.music.vt.edu
+	t_clock *x_clock;
+
+	pthread_t unsafe_t;
+	pthread_mutex_t unsafe_mutex;
+	pthread_cond_t unsafe_cond;
+
+	t_symbol *x_s;
+	t_int unsafe;
 } t_coll;
 
+typedef struct _threadedFunctionParams
+{
+	t_coll *x;
+} t_threadedFunctionParams;
+
 static t_class *coll_class;
 static t_class *collcommon_class;
 
+void coll_tick(t_coll *x)
+{
+	//x->busy = 0;
+outlet_bang(x->x_filebangout);
+}
+
 static t_collelem *collelem_new(int ac, t_atom *av, int *np, t_symbol *s)
 {
 t_collelem *ep = (t_collelem *)getbytes(sizeof(*ep));
@@ -201,6 +226,8 @@
 }
 }
 
+
+
 /* atomic collcommon modifiers:  clearall, remove, replace,
putbefore, putafter, swaplinks, swapkeys, changesymkey, renumber, sort */
 
@@ -621,7 +648,7 @@
 	t_coll *x;
 	/* LATER consider making this more robust */
 	for (x = cc->c_refs; x; x = x->x_next)
-		outlet_bang(x->x_filebangout);
+		//outlet_bang(x->x_filebangout);
 	cc->c_lastcanvas = cv;
 	cc->c_filename = fn;
 	post("coll: finished reading %d lines from text file '%s'",
@@ -952,234 +979,264 @@
 
 static void coll_float(t_coll *x, t_float f)
 {
-t_collcommon *cc = x->x_common;
-t_collelem *ep;
-int numkey;
-if (loud_checkint((t_pd *)x, f, &numkey, &s_float) &&
-	(ep = collcommon_numkey(cc, numkey)))
-{
-	coll_keyoutput(x, ep);
-	if (!cc->c_selfmodified || (ep = collcommon_numkey(cc, numkey)))
-	coll_dooutput(x, ep->e_size, ep->e_data);
-}
+	//if (!x->busy) {
+		t_collcommon *cc = x->x_common;
+		t_collelem *ep;
+		int numkey;
+		if (loud_checkint((t_pd *)x, f, &numkey, &s_float) &&
+		(ep = collcommon_numkey(cc, numkey)))
+		{
+		coll_keyoutput(x, ep);
+		if (!cc->c_selfmodified || (ep = collcommon_numkey(cc, numkey)))
+			coll_dooutput(x, ep->e_size, ep->e_data);
+		}
+	//}
 }
 
 static void coll_symbol(t_coll *x, t_symbol *s)
 {
-t_collcommon *cc = x->x_common;
-t_collelem *ep;
-if (ep = collcommon_symkey(cc, s))
-{
-	coll_keyoutput(x, ep);
-	if (!cc->c_selfmodified || (ep = collcommon_symkey(cc, s)))
-	coll_dooutput(x, ep->e_size, ep->e_data);
-}
+	//if (!x->busy) {
+		t_collcommon *cc = x->x_common;
+		t_collelem *ep;
+		if (ep = collcommon_symkey(cc, s))
+		{
+		coll_keyoutput(x, ep);
+		if (!cc->c_selfmodified || (ep = collcommon_symkey(cc, s)))
+			coll_dooutput(x, ep->e_size, ep->e_data);
+		}
+	//}
 }
 
 static void coll_list(t_coll *x, t_symbol *s, int ac, t_atom *av)
 {
-if (ac >= 2 && av->a_type == A_FLOAT)
-	coll_tokey(x, av, ac-1, av+1, 1, &s_list);
-else
-	loud_messarg((t_pd *)x, &s_list);
+	//if (!x->busy) {
+		if (ac >= 2 && av->a_type == A_FLOAT)
+		coll_tokey(x, av, ac-1, av+1, 1, &s_list);
+		else
+		loud_messarg((t_pd *)x, &s_list);
+	//}
 }
 
 static void coll_anything(t_coll *x, t_symbol *s, int ac, t_atom *av)
 {
-coll_symbol(x, s);
+	//if (!x->busy)
+	coll_symbol(x, s);
 }
 
 static void coll_store(t_coll *x, t_symbol *s, int ac, t_atom *av)
 {
-if (ac >= 2)
-	coll_tokey(x, av, ac-1, av+1, 1, s);
-else
-	loud_messarg((t_pd *)x, s);
+	//if (!x->busy) {
+		if (ac >= 2)
+		coll_tokey(x, av, ac-1, av+1, 1, s);
+		else
+		loud_messarg((t_pd *)x, s);
+	//}
 }
 
 static void coll_nstore(t_coll *x, t_symbol *s, int ac, t_atom *av)
 {
-if (ac >= 3)
-{
-	t_collcommon *cc = x->x_common;
-	t_collelem *ep;
-	int numkey;
-	if (av->a_type == A_FLOAT && av[1].a_type == A_SYMBOL)
-	{
-	if (loud_checkint((t_pd *)x, av->a_w.w_float, &numkey, s))
-	{
-		if (ep = collcommon_symkey(cc, av[1].a_w.w_symbol))
-		collcommon_remove(cc, ep);
-		ep = collcommon_tonumkey(cc, numkey, ac-2, av+2, 1);
-		ep->e_symkey = av[1].a_w.w_symbol;
-	}
-	}
-	else if (av->a_type == A_SYMBOL && av[1].a_type == A_FLOAT)
-	{
-	if (loud_checkint((t_pd *)x, av[1].a_w.w_float, &numkey, s))
-	{
-		if (ep = collcommon_numkey(cc, numkey))
-		collcommon_remove(cc, ep);
-		ep = collcommon_tosymkey(cc, av->a_w.w_symbol, ac-2, av+2, 1);
-		ep->e_hasnumkey = 1;
-		ep->e_numkey = numk

[PD] odd key object behavior under Linux

[Ivica Ico Bukvic]

In my recent troubleshooting saga dealing with xruns and coll object I
identified one rather odd behavior that apparently stems from the [key]
object.

It all started when I noticed that my threaded version of coll object
tended to freeze Pd at apparently random points. As it turns out, I was
testing its robustness simply by passing a key into a read/write message
and holding the key down to generate a large number of requests per
second and the [key] object at times seemed to spit out (while
autorepeat of the pressed key was taking place) two outputs at the same
time which in turn crashed Pd as threaded coll object did not handle
this gracefully. I've since fixed the coll object but the key behavior
baffles me.

The double redundant output is apparent in both rt and non-rt Pd (on
Ubuntu 9.10 using rt kernel on the MSI Wind atom netbook) and below is
the simplest patch to invoke this.

Basically, I am measuring the aforesaid time delta between broadcast
strokes using timer object and printing it out to console.

#N canvas 549 345 383 297 10;
#X obj 162 83 key;
#X obj 162 107 sel 32;
#X text 208 108 space;
#X obj 162 145 timer;
#X obj 162 182 print;
#X connect 0 0 1 0;
#X connect 1 0 3 1;
#X connect 1 0 3 0;
#X connect 3 0 4 0;

So, while certainly the fact that threaded version of coll wasn't
handling gracefully multiple redundant requests at the same time was a
bug (which I am hoping has been fixed now), I am wondering whether the
aforesaid [key] behavior might be a bug as it seems to me that
keystrokes of the same key, even if the key is autorepeating should
never have a time delta of zero. Naturally, one can always put a
speedlim after the [key] object but that might result in a truncated
output of fast typing.

I would greatly appreciate it if others can test this to see if they are
getting the same results.

FWIW, allowing this kind of key behavior in more complex patches did
result in the pd<->gui communication tearing with the stderr reporting
several truncated messages before crashing. Due to their complexity and
unpredictability of a point where tearing would occur I am not sure
where the problem might be stemming from but it is undoubtedly at least
in part instigated by double redundant output from the key object
possibly in conjunction with objects that may have not provided graceful
handling of such requests.

NB: I only tested the same patch on Win platform and there it does not
exhibit this problem.

Any thoughts would be most appreciated.

Best wishes,

Ico


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

Re: [PD] [PD-dev] odd key object behavior under Linux

[Ivica Ico Bukvic]

Many thanks for the explanation! What seems weird, however, is how divergent 
time delta between repeats is. On Windows it is always around 30ms (at least on 
my hardware) whereas on Linux it goes between 0, including 1.4ms and up to 50+. 
Even when accounting for jitter between two events I cannot imagine that they 
oscillate that much (unless my flavor of kernel/hardware treats keypress timing 
like a dirt :-).

Best wishes,

Ico

martin.pe...@sympatico.ca wrote:

>
>It probably happens when you get two keydowns in the space of one Pd event 
>loop. The second is output at the same time. The same thing happens with 
>[metro] banging serial data into [comport] or [midiout]. The metro rate is 
>quantized to the event loop rate, so individual bangs are irregularly spaced 
>but the mean time over many bangs is perfect. The only way to get perfect 
>timing is to use signals, messages are always handled after the sound has been 
>computed.
>So if you don't like it you could slow down your keyboard repeat rate to 
>slower than Pd, or use a microphone to detect the keypresses ;)
>
>Martin
>
>
>
>
>Ico wrote:
>
>> It all started when I noticed that my threaded version of coll object
>> tended to freeze Pd at apparently random points. As it turns out, I was
>> testing its robustness simply by passing a key into a read/write message
>> and holding the key down to generate a large number of requests per
>> second and the [key] object at times seemed to spit out (while
>> autorepeat of the pressed key was taking place) two outputs at the same
>> time which in turn crashed Pd as threaded coll object did not handle
>> this gracefully. I've since fixed the coll object but the key behavior
>> baffles me.
>>
>> The double redundant output is apparent in both rt and non-rt Pd (on
>> Ubuntu 9.10 using rt kernel on the MSI Wind atom netbook) and below is
>> the simplest patch to invoke this.
>>
>> Basically, I am measuring the aforesaid time delta between broadcast
>> strokes using timer object and printing it out to console.
>>
>> #N canvas 549 345 383 297 10;
>> #X obj 162 83 key;
>> #X obj 162 107 sel 32;
>> #X text 208 108 space;
>> #X obj 162 145 timer;
>> #X obj 162 182 print;
>> #X connect 0 0 1 0;
>> #X connect 1 0 3 1;
>> #X connect 1 0 3 0;
>> #X connect 3 0 4 0;
>>
>> So, while certainly the fact that threaded version of coll wasn't
>> handling gracefully multiple redundant requests at the same time was a
>> bug (which I am hoping has been fixed now), I am wondering whether the
>> aforesaid [key] behavior might be a bug as it seems to me that
>> keystrokes of the same key, even if the key is autorepeating should
>> never have a time delta of zero. Naturally, one can always put a
>> speedlim after the [key] object but that might result in a truncated
>> output of fast typing.
>>
>> I would greatly appreciate it if others can test this to see if they are
>> getting the same results.
>>
>> FWIW, allowing this kind of key behavior in more complex patches did
>> result in the pd<->gui communication tearing with the stderr reporting
>> several truncated messages before crashing. Due to their complexity and
>> unpredictability of a point where tearing would occur I am not sure
>> where the problem might be stemming from but it is undoubtedly at least
>> in part instigated by double redundant output from the key object
>> possibly in conjunction with objects that may have not provided graceful
>> handling of such requests.
>>
>> NB: I only tested the same patch on Win platform and there it does not
>> exhibit this problem.
>>
>> Any thoughts would be most appreciated.
>>
>> Best wishes,
>>
>> Ico
>>
>>
>> ___
>> Pd-dev mailing list
>> pd-...@iem.at
>> http://lists.puredata.info/listinfo/pd-dev
> 
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-dev] odd key object behavior under Linux

[Ivica Ico Bukvic]

What is the range of the graph? How many hits is your graph showing?

 

Would this perhaps warrant a small adjustment to Linux code where it checks 
whether the key of certain type has been outputted in this update and if so, 
discard repeated occurrence?

 

Best wishes,

 

Ico

 

  _  

From: tim vets [mailto:timv...@gmail.com] 
Sent: Monday, September 27, 2010 1:21 PM
To: Ivica Ico Bukvic
Cc: martin.pe...@sympatico.ca; pd-list@iem.at; pd-...@iem.at
Subject: Re: [PD] [PD-dev] odd key object behavior under Linux

 

I got curious, so I did this little test with auto-repeated keys:

keytimetest.jpg

strange indeed :)

gr,

Tim

 

 

2010/9/27 Ivica Ico Bukvic 

Many thanks for the explanation! What seems weird, however, is how divergent 
time delta between repeats is. On Windows it is always around 30ms (at least on 
my hardware) whereas on Linux it goes between 0, including 1.4ms and up to 50+. 
Even when accounting for jitter between two events I cannot imagine that they 
oscillate that much (unless my flavor of kernel/hardware treats keypress timing 
like a dirt :-).

Best wishes,

Ico


martin.pe...@sympatico.ca wrote:

>
>It probably happens when you get two keydowns in the space of one Pd event 
>loop. The second is output at the same time. The same thing happens with 
>[metro] banging serial data into [comport] or [midiout]. The metro rate is 
>quantized to the event loop rate, so individual bangs are irregularly spaced 
>but the mean time over many bangs is perfect. The only way to get perfect 
>timing is to use signals, messages are always handled after the sound has been 
>computed.
>So if you don't like it you could slow down your keyboard repeat rate to 
>slower than Pd, or use a microphone to detect the keypresses ;)
>
>Martin
>
>
>
>
>Ico wrote:
>
>> It all started when I noticed that my threaded version of coll object
>> tended to freeze Pd at apparently random points. As it turns out, I was
>> testing its robustness simply by passing a key into a read/write message
>> and holding the key down to generate a large number of requests per
>> second and the [key] object at times seemed to spit out (while
>> autorepeat of the pressed key was taking place) two outputs at the same
>> time which in turn crashed Pd as threaded coll object did not handle
>> this gracefully. I've since fixed the coll object but the key behavior
>> baffles me.
>>
>> The double redundant output is apparent in both rt and non-rt Pd (on
>> Ubuntu 9.10 using rt kernel on the MSI Wind atom netbook) and below is
>> the simplest patch to invoke this.
>>
>> Basically, I am measuring the aforesaid time delta between broadcast
>> strokes using timer object and printing it out to console.
>>
>> #N canvas 549 345 383 297 10;
>> #X obj 162 83 key;
>> #X obj 162 107 sel 32;
>> #X text 208 108 space;
>> #X obj 162 145 timer;
>> #X obj 162 182 print;
>> #X connect 0 0 1 0;
>> #X connect 1 0 3 1;
>> #X connect 1 0 3 0;
>> #X connect 3 0 4 0;
>>
>> So, while certainly the fact that threaded version of coll wasn't
>> handling gracefully multiple redundant requests at the same time was a
>> bug (which I am hoping has been fixed now), I am wondering whether the
>> aforesaid [key] behavior might be a bug as it seems to me that
>> keystrokes of the same key, even if the key is autorepeating should
>> never have a time delta of zero. Naturally, one can always put a
>> speedlim after the [key] object but that might result in a truncated
>> output of fast typing.
>>
>> I would greatly appreciate it if others can test this to see if they are
>> getting the same results.
>>
>> FWIW, allowing this kind of key behavior in more complex patches did
>> result in the pd<->gui communication tearing with the stderr reporting
>> several truncated messages before crashing. Due to their complexity and
>> unpredictability of a point where tearing would occur I am not sure
>> where the problem might be stemming from but it is undoubtedly at least
>> in part instigated by double redundant output from the key object
>> possibly in conjunction with objects that may have not provided graceful
>> handling of such requests.
>>
>> NB: I only tested the same patch on Win platform and there it does not
>> exhibit this problem.
>>
>> Any thoughts would be most appreciated.
>>
>> Best wishes,
>>
>> Ico
>>
>>
>> ___
>> Pd-dev mailing list
>> pd-...@iem.at
>> http://lists.puredata.info/listinfo/pd-dev
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

 

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

Re: [PD] GUI speed

[Ivica Ico Bukvic]

Another thing to consider is if you have large GUI objects that are updating 
quickly (e.g. number2 with huge fonts). This will also potentially tax the cpu.

Bernardo Barros  wrote:

>you can post your patch, so maybe we will discover the problem.
>for the abstraction one solution is to change the name of your hacked
>abstractions and send them as well.
>
>2010/9/27 András Murányi :
>> well, i meant a bug in my patch...
>> what i understood was that it overloaded the CPU on João's box too
>>
>> 2010/9/28 Bernardo Barros 
>>>
>>> maybe this is a bug od pd-gui?
>>> (well, poor performance *is* a bug)
>>>
>>> 2010/9/27 András Murányi :
>>> > On Mon, Sep 27, 2010 at 11:45 AM, João Pais 
>>> > wrote:
>>> >>>
>>> >>> Well, it's not very exportable as i have modified/overwritten some
>>> >>> abstractions made by others. Baaad practice!
>>> >>> I'm trying to attach it now and i hope i works. Need pd-extended and
>>> >>> many
>>> >>> libs from it, moonlib for sure.
>>> >>
>>> >> not much, some abstractions are missing.
>>> >>
>>> >> anyway, even with the patch not working, I can see something is
>>> >> definitively wrong. just by opening it with audio off, I get consistent
>>> >> 50%
>>> >> cpu usage - which means it's using a whole processor of my dual core.
>>> >> unless
>>> >> one of the missing abs is the problem, I would suggest you spend some
>>> >> hours
>>> >> bug tracking.
>>> >
>>> > yes, i've spent some nights bug tracking, and at one point i thought ask
>>> > the
>>> > list too... :o)
>>> > something is definitely wrong!
>>> >
>>> >
>>> >> On Mon, Sep 27, 2010 at 3:34 PM, Ivica Ico Bukvic  wrote:
>>> >> FWIW you may want to try to simply cut pieces of the patch while it is
>>> >> running and observe the cpu load meter until it drops. That way you
>>> >> should
>>> >> be able to locate the problem quicker.
>>> >>
>>> >
>>> > yes, i was trying thing like this, and will go on until i find what i
>>> > messed
>>> > up.
>>> > I was just starting to think that it's normal and i have to live with it
>>> > (or
>>> > get a few more CPU cores) but now you guys reassured me that the bug is
>>> > somewhere... in the haystack
>>> >
>>> > Andras
>>> >
>>> > ___
>>> > Pd-list@iem.at mailing list
>>> > UNSUBSCRIBE and account-management ->
>>> > http://lists.puredata.info/listinfo/pd-list
>>> >
>>> >
>>
>>
>>
>> --
>> Muranyi Andras
>>
>
>___
>Pd-list@iem.at mailing list
>UNSUBSCRIBE and account-management -> 
>http://lists.puredata.info/listinfo/pd-list
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] question about multithreaded externals in Pd

[Ivica Ico Bukvic]

2007), www.mikewoz.com
//
// Requires the CWiid library (version 0.6.00) by L. Donnie Smith
//
// ===
// This program is free software; you can redistribute it and/or modify
// it under the terms of the GNU General Public License as published by
// the Free Software Foundation; either version 2 of the License, or
// (at your option) any later version.
//
// This program is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
// GNU General Public License for more details.
//
// You should have received a copy of the GNU General Public License
// along with this program; if not, write to the Free Software
// Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
// ===

//  ChangeLog:
//  2008-04-14 Florian Krebs 
//  * adapt wiimote external for the actual version of cwiid (0.6.00)

//  ChangeLog:
//  2009-06-09 DISIS (Michael Hawthorne  & Ivica Ico Bukvic )
//  http://disis.music.vt.edu
//  * Bug-fixes (connecting and disconnecting crashes)
//  * Multithreaded implementation to prevent wiimote from starving PD audio thread
//  * Bang implementation to allow for better data rate control
//  * Updated help file

//  v 0.6.3 Changelog:
//  2009-10-05 DISIS (Ivica Ico Bukvic )
//  http://disis.music.vt.edu
//  * Total rewrite of the threaded design and tons of clean-up

//  v0.6.4 Changelog:
//  2010-03-21 DISIS (Ivica Ico Bukvic )
//  http://disis.music.vt.edu
//  * Reworked signalling system to use clock_delay()

//  v0.6.5 Changelog:
//  2010-09-15 DISIS (Ivica Ico Bukvic )
//  http://disis.music.vt.edu
//  * Added motionplus support
//	* Squashed bugs where expansion was not recognized on connect
//	* Fixed incorrect calibration on connect
//	* Other minor bugs'n'fixes

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include "cwiid_internal.h"
#define PI	3.14159265358979323

//#define DARWIN_CALIB

struct acc {
	unsigned char x;
	unsigned char y;
	unsigned char z;
};

/* Wiimote Callback */
cwiid_mesg_callback_t pd_cwiid_callback;

// class and struct declarations for wiimote pd external:
static t_class *pd_cwiid_class;
typedef struct _wiimote
{
	t_object x_obj; // standard pd object (must be first in struct)
	
	cwiid_wiimote_t *wiimote; // individual wiimote handle per pd object, represented in libcwiid

	t_float connected;
	int wiimoteID;
	int extensionAttached;

	//Creating separate threads for actions known to cause sample drop-outs
	pthread_t unsafe_t;
	pthread_mutex_t unsafe_mutex;
	pthread_cond_t unsafe_cond;

	t_float unsafe;

	t_float rumble;
	t_float led;
	t_float rpt;
	unsigned char rpt_mode;

	t_symbol *addr;

	t_float toggle_acc, toggle_ir, toggle_nc;

	struct acc acc_zero, acc_one; // acceleration
	struct acc nc_acc_zero, nc_acc_one; // nunchuck acceleration

	// We store atom list for each data type so we don't waste time
	// allocating memory at every callback:
	t_atom btn_atoms[2];
	t_atom old_btn_atoms[2];
	t_atom acc_atoms[3];
	t_atom ir_atoms[4];
	t_atom nc_btn_atoms[1];
	t_atom old_nc_btn_atoms[1];
	t_atom nc_acc_atoms[3];
	t_atom nc_stick_atoms[2];
	t_atom mp_acc_atoms[3];		//motionplus

	//for thread-unsafe operations
	t_clock *x_clock;
	
	// outlets:
	t_outlet *outlet_btn;
	t_outlet *outlet_acc;
	t_outlet *outlet_ir;
	t_outlet *outlet_nc_btn;
	t_outlet *outlet_nc_acc;
	t_outlet *outlet_nc_stick;
	t_outlet *outlet_mp_acc;
	t_outlet *outlet_connected;
	
} t_wiimote;

// For now, we make one global t_wiimote pointer that we can refer to
// in the cwiid_callback. This means we can support maximum of ONE
// wiimote. ARGH. We'll have to figure out how to have access to the
// pd object from the callback (without modifying the CWiid code):
#define MAX_WIIMOTES 1
t_wiimote *g_wiimoteList[MAX_WIIMOTES];

// Structure to pass generic parameters into a threaded function.
// Added by VT DISIS
typedef struct
{
	t_wiimote *wiimote;
} threadedFunctionParams;

// ==

void pd_cwiid_tick(t_wiimote *x)
{
outlet_float(x->outlet_connected, x->connected);
}

void pd_cwiid_debug(t_wiimote *x)
{
	post("\n==");
	if (x->connected) post("Wiimote (id: %d) is connected.", x->wiimoteID);
	else post("Wiimote (id: %d) is NOT connected.", x->wiimoteID);
	if (x->toggle_acc) post("acceleration: ON");
	else post("acceleration: OFF");
	if (x->toggle_ir)  post("IR:   ON");
	else post("IR:   OFF");
	if (x->toggle_nc)  post("Nunchuck: ON");
	else post("Nunchuck: OFF");
	post("");
	post("Accelerometer calibration: zero=(%d,%d,%d) one=(%d,%d,%d)",x-

Re: [PD] [PD-dev] question about multithreaded externals in Pd

[Ivica Ico Bukvic]

First of all, my apologies to all for x-posting of the original
matter--I did not realize there was such a major overlap in user base on
pd-list and pd-dev lists making my x-post truly redundant.

> since rPars can't be used by any other thread, you need to make a copy 
> for each thread.

This must be it! You are absolutely right as there is no guarantee rPars
won't get destructed (with the end of the constructor function) before
the worker thread is properly instantiated. FWIW, instead of creating a
copy of rPars, I've actually gone with Robin's suggestion to use
sched_yield() and have a wait condition which is cleared once the worker
thread has spawned to ensure it will get the necessary data from rPars
before they are destructed as follows:

void *pd_cwiid_pthreadForAudioUnfriendlyOperations(void *ptr)
{
threadedFunctionParams *rPars = (threadedFunctionParams*)ptr;
t_wiimote *x = rPars->wiimote;
t_float local_led = 0;
t_float local_rumble = 0;
unsigned char local_rpt_mode = x->rpt_mode;

while(x->unsafe > -1) {
pthread_mutex_lock(&x->unsafe_mutex);
if ((local_led == x->led) && (local_rumble == x->rumble) &&
(local_rpt_mode == x->rpt_mode)) {
if (x->unsafe) x->unsafe = 0; //signal that the thread 
init is
complete
pthread_cond_wait(&x->unsafe_cond, &x->unsafe_mutex);
}

//snip

static void *pd_cwiid_new(t_symbol* s, int argc, t_atom *argv)
{

//snip

// spawn threads for actions known to cause sample drop-outs
threadedFunctionParams rPars;
rPars.wiimote = x;
pthread_mutex_init(&x->unsafe_mutex, NULL);
pthread_cond_init(&x->unsafe_cond, NULL);
pthread_create( &x->unsafe_t, NULL, (void *)
&pd_cwiid_pthreadForAudioUnfriendlyOperations, (void *) &rPars);

// wait until other thread has properly intialized so that
// rPars do not get destroyed before the thread has gotten its
// pointer information
while(x->unsafe) {
//must use as many yields as necessary as there is no
//guarantee that one will be enough
//also on Linux use sched_yield
//rather than pthread_yield
sched_yield();
}

//snip

Many thanks all for your help on this one! Hopefully the existence of
this thread will help others who may be looking for similar solutions.

Best wishes,

Ico


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

Re: [PD] PD on Atom Processors

[Ivica Ico Bukvic]

FWIW L2Ork (http://l2ork.music.vt.edu  ) runs 
entirely on MSI Wind U100 netbooks with Atom processors. Everything works just 
fine. You will top off the CPU relatively quickly as these things are not built 
for speed. Still, you should get a decent amount of performance out of them. I 
haven’t used much Gem (yet) but did construct a few test patches and it did 
behave perfectly fine, even with Compiz on. The only device that has shown some 
instability is wireless which can occasionally drop a wireless connection 
(although this may be simply because I am running an older version of Ubuntu, 
namely 9.10).

 

HTH

 

Best wishes,

 

Ico

 

  _  

From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of Felix 
Obée
Sent: Sunday, October 03, 2010 3:03 PM
To: pd-list@iem.at
Subject: [PD] PD on Atom Processors

 

Hi together,

 

is there someone who has experience running PD on Atom machines?

 

I want to realize a simple video player for an installation using PD / GEM and 
an Arduino as Interface. The machine I am thinking about is a MSI Windbox 
running Linux,  booting from USB and playing the Videos on an SD-Card.

Since Linux is preinstalled on the machine I expect no problems with the 
graphic drivers...

Specs are:

 

• Suse Linux Enterprise 11
• Intel® Atom™ Prozessor D510
(1,66 GHz, 1 MB L2 Cache)
• 320 GB HD und 2 GB Ram
• ATI® Radeon™ HD4330 Grafik, 256 MB 
• Intel® NM10 Express
• WLAN 802.11 b/g/n und Gbit LAN
• eSATA-Anschluß, SPDIF out Adapter
• HDMI- und VGA-Ausgang
• 6 in 1 Card Reader und 4 USB Ports

 

http://de.msi.com/index.php?func=prodtmpspec 

 &maincat_no=134&cat2_no=&cat3_no=&prod_no=2002#menu

 

Thx for the help!

 

Felix

 

...
---
Felix Obée
Weichselstr. 35
12045 Berlin

Phone: 0178 / 49 31 008

Phone: 030 / 55957397
Mail: fe...@amphibiousthoughts.com
http://amphibiousthoughts.com

http://dj.amphibiousthoughts.com
---

 

 

 

 

 

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

Re: [PD] ugly fonts under pdextended 0.42.5

[Ivica Ico Bukvic]

FWIW, you can also try L2Ork version of pd-extended that includes a lot of 
goodies found in 0.43, including 8.5 tk support. It is however currently 
Linux-only.

Bug-fixes/reports are as always welcome.

Ico

Hans-Christoph Steiner  wrote:

>
>That's how Pd looks using Tcl/Tk 8.4  0.42.5 does not fully support  
>Tcl/Tk newer than that, so Pd-extended uses 8.4.  You can build Pd- 
>extended against Tcl/Tk 8.5 if you want, or wait for Pd 0.43, which is  
>fully compatible with Tcl/Tk 8.5 or newer.
>
>.hc
>
>On Oct 5, 2010, at 3:51 PM, Erik Maes wrote:
>
>> Repost; didn't make it to the list somehow.
>>
>> Hi,
>>
>> I have the same problem. after enabling the repo on Ubuntu Lucid,
>> aptitude first removed tk8.5. I reinstalled tk, but to no avail, and
>> update-alternatives didn't help either.
>> screenshot: 
>>
>>
>> On Tue, 2010-10-05 at 11:09 +0200, Hans-Christoph Steiner wrote:
>>> Can you post screenshots somewhere?
>>>
>>> .hc
>>>
>>> On Oct 4, 2010, at 3:02 PM, michael noble wrote:
>>>
 Hi Hans,

 Neither reinstalling the fonts or switching to Tcl/Tk 8.5 made a
 difference. Fonts in PD vanilla (0.42.6 from the repos) look fine,  
 by
 the way. This is in Lucid and Maverick, not able to test on  
 Squeeze at
 the moment.

 -m
>>>
>>>
>>>
>>>
>>>
>>> 
>>>
>>> "Free software means you control what your computer does. Non-free
>>> software means someone else controls that, and to some extent  
>>> controls
>>> you." - Richard M. Stallman
>>>
>>>
>>>
>>> ___
>>> Pd-list@iem.at mailing list
>>> UNSUBSCRIBE and account-management -> 
>>> http://lists.puredata.info/listinfo/pd-list
>>
>>
>>
>
>
>
>
>
>"We have nothing to fear from love and commitment." - New York Senator  
>Diane Savino, trying to convince the NY Senate to pass a gay marriage  
>bill
>
>
>___
>Pd-list@iem.at mailing list
>UNSUBSCRIBE and account-management -> 
>http://lists.puredata.info/listinfo/pd-list
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-dev] odd key object behavior under Linux

[Ivica Ico Bukvic]

Indeed. However, does Linux's API allow for this? 

 

  _  

From: Hans-Christoph Steiner [mailto:h...@at.or.at] 
Sent: Sunday, October 10, 2010 6:26 PM
To: tim vets
Cc: Ivica Ico Bukvic; pd-list@iem.at; martin.pe...@sympatico.ca; pd-...@iem.at
Subject: Re: [PD] [PD-dev] odd key object behavior under Linux

 

 

One thing that would make a lot of sense is to make the [key] object only 
output keydown and keyup events, and not output the auto-generated repeats.

 

.hc

 

On Sep 28, 2010, at 1:51 AM, tim vets wrote:






2010/9/28 Ivica Ico Bukvic 

What is the range of the graph? How many hits is your graph showing?

 

 

if you're talking about my graph:

the actual keyboard autorepeat rate here is at about 30 ms

with these mysterious regularly alternating highs and lows.

The other peaks in the graph are just where I released a key for a while to 
choose another test key to hold down.

arrow keys show a different result than, say, a letter key...

(test done here on "Ubuntu 8.04 - the Hardy Heron", Pd version 0.41.4-extended)

gr,

Tim

 

Would this perhaps warrant a small adjustment to Linux code where it checks 
whether the key of certain type has been outputted in this update and if so, 
discard repeated occurrence?

 

Best wishes,

 

Ico

 


  _  


From: tim vets [mailto:timv...@gmail.com] 
Sent: Monday, September 27, 2010 1:21 PM
To: Ivica Ico Bukvic
Cc: martin.pe...@sympatico.ca; pd-list@iem.at; pd-...@iem.at
Subject: Re: [PD] [PD-dev] odd key object behavior under Linux

 

I got curious, so I did this little test with auto-repeated keys:



strange indeed :)

gr,

Tim

 

 

2010/9/27 Ivica Ico Bukvic 

Many thanks for the explanation! What seems weird, however, is how divergent 
time delta between repeats is. On Windows it is always around 30ms (at least on 
my hardware) whereas on Linux it goes between 0, including 1.4ms and up to 50+. 
Even when accounting for jitter between two events I cannot imagine that they 
oscillate that much (unless my flavor of kernel/hardware treats keypress timing 
like a dirt :-).

Best wishes,

Ico


martin.pe...@sympatico.ca wrote:

>
>It probably happens when you get two keydowns in the space of one Pd event 
>loop. The second is output at the same time. The same thing happens with 
>[metro] banging serial data into [comport] or [midiout]. The metro rate is 
>quantized to the event loop rate, so individual bangs are irregularly spaced 
>but the mean time over many bangs is perfect. The only way to get perfect 
>timing is to use signals, messages are always handled after the sound has been 
>computed.
>So if you don't like it you could slow down your keyboard repeat rate to 
>slower than Pd, or use a microphone to detect the keypresses ;)
>
>Martin
>
>
>
>
>Ico wrote:
>
>> It all started when I noticed that my threaded version of coll object
>> tended to freeze Pd at apparently random points. As it turns out, I was
>> testing its robustness simply by passing a key into a read/write message
>> and holding the key down to generate a large number of requests per
>> second and the [key] object at times seemed to spit out (while
>> autorepeat of the pressed key was taking place) two outputs at the same
>> time which in turn crashed Pd as threaded coll object did not handle
>> this gracefully. I've since fixed the coll object but the key behavior
>> baffles me.
>>
>> The double redundant output is apparent in both rt and non-rt Pd (on
>> Ubuntu 9.10 using rt kernel on the MSI Wind atom netbook) and below is
>> the simplest patch to invoke this.
>>
>> Basically, I am measuring the aforesaid time delta between broadcast
>> strokes using timer object and printing it out to console.
>>
>> #N canvas 549 345 383 297 10;
>> #X obj 162 83 key;
>> #X obj 162 107 sel 32;
>> #X text 208 108 space;
>> #X obj 162 145 timer;
>> #X obj 162 182 print;
>> #X connect 0 0 1 0;
>> #X connect 1 0 3 1;
>> #X connect 1 0 3 0;
>> #X connect 3 0 4 0;
>>
>> So, while certainly the fact that threaded version of coll wasn't
>> handling gracefully multiple redundant requests at the same time was a
>> bug (which I am hoping has been fixed now), I am wondering whether the
>> aforesaid [key] behavior might be a bug as it seems to me that
>> keystrokes of the same key, even if the key is autorepeating should
>> never have a time delta of zero. Naturally, one can always put a
>> speedlim after the [key] object but that might result in a truncated
>> output of fast typing.
>>
>> I would greatly appreciate it if others can test this to see if they are
>> getting the same results.
>>
>> FWIW, allowing this kind of key behavior in more complex patches did
&

Re: [PD] Microsound

[Ivica Ico Bukvic]

 One of the more common techniques associated to microsound
  is granular synthesis,  

 book >>  "microsound" by curtis road

 pd tutorial >> http://www.pd-tutorial.com by Johannes Kreidler   3.7 granular 
synthesis

PD granulators:  particlechamber by Derek  Holzer   
http://puredata.info/community/patches

pulsegrain by nullpointer  
http://www.nullpointer.co.uk/-/pd.htm

nm-grainer by Nick Mariete 

   
http://puredata.info/Members/nmariette/granular-implementations

   granulator by ch   in the externat lib nusmuk included at 
pd-extended



You can also check out disis_munger~ which is an updated/enhanced version of 
munger~ from the PeRcolate library and which apparently never worked quite 
right on PD/Linux.

 

HTH

 

Ico

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

Re: [PD] Microsound

[Ivica Ico Bukvic]

It seems I worded my original email clumsily. AFAIK munger~ never worked for me 
which is why in part we built DISIS_munger~ (which does work).

oskoff lovich  wrote:

>> You can also check out disis_munger~ which is an updated/enhanced version of
>> munger~ from the PeRcolate library and which apparently never worked quite
>> right on PD/Linux.
>
>munger~ and disis_munger~  working very well on PD/Linux
>
>
>
>2010/10/18, Ivica Ico Bukvic :
>>  One of the more common techniques associated to microsound
>>   is granular synthesis,
>>
>>  book >>  "microsound" by curtis road
>>
>>  pd tutorial >> http://www.pd-tutorial.com by Johannes Kreidler   3.7
>> granular synthesis
>>
>> PD granulators:  particlechamber by Derek  Holzer
>> http://puredata.info/community/patches
>>
>> pulsegrain by nullpointer
>> http://www.nullpointer.co.uk/-/pd.htm
>>
>> nm-grainer by Nick Mariete
>>
>>
>> http://puredata.info/Members/nmariette/granular-implementations
>>
>>granulator by ch   in the externat lib nusmuk included at
>> pd-extended
>>
>>
>>
>> You can also check out disis_munger~ which is an updated/enhanced version of
>> munger~ from the PeRcolate library and which apparently never worked quite
>> right on PD/Linux.
>>
>>
>>
>> HTH
>>
>>
>>
>> Ico
>>
>>
>
>
>-- 
>>>>http://noconventions.mobi/noish
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] Trying to track a ghost pdtk_canvas_getscroll call

[Ivica Ico Bukvic]

Hi all,

I have a real pickle in trying to debug Pd. Namely, when I grep-ed every
single instance of pdtk_canvas_getscroll and commented it out, it still
gets invoked somehow and I am at a loss how. I know it occurs as many
times as there are objects selected that have been moved (so it is
definitely per-object) 

The only thing I managed to isolate so far is the following code:
g_editor.c

void gobj_displace(t_gobj *x, t_glist *glist, int dx, int dy)
{
if (x->g_pd->c_wb && x->g_pd->c_wb->w_displacefn)
(*x->g_pd->c_wb->w_displacefn)(x, glist, dx, dy);
}

I am however unable to decipher what function is exactly being called by
(*x->g_pd->c_wb->w_displacefn). I only found in g_canvas.h definition of
w_displacefn as part of _widgetbehavior struct but nowhere (except in
iemgui objects) is it linked to anything I can actually understand.
Where does this struct get initialized?

Any help on this one would be most appreciated as that will put a stop
on me pulling my hairs out :-)

Best wishes,

Ico


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

Re: [PD] Trying to track a ghost pdtk_canvas_getscroll call

[Ivica Ico Bukvic]

Never mind... My brain finally decided to get out of bed and join me in
my office... Apologies for spam...

On Thu, 2010-11-18 at 11:22 -0500, Ivica Ico Bukvic wrote:
> Hi all,
> 
> I have a real pickle in trying to debug Pd. Namely, when I grep-ed every
> single instance of pdtk_canvas_getscroll and commented it out, it still
> gets invoked somehow and I am at a loss how. I know it occurs as many
> times as there are objects selected that have been moved (so it is
> definitely per-object) 
> 
> The only thing I managed to isolate so far is the following code:
> g_editor.c
> 
> void gobj_displace(t_gobj *x, t_glist *glist, int dx, int dy)
> {
> if (x->g_pd->c_wb && x->g_pd->c_wb->w_displacefn)
> (*x->g_pd->c_wb->w_displacefn)(x, glist, dx, dy);
> }
> 
> I am however unable to decipher what function is exactly being called by
> (*x->g_pd->c_wb->w_displacefn). I only found in g_canvas.h definition of
> w_displacefn as part of _widgetbehavior struct but nowhere (except in
> iemgui objects) is it linked to anything I can actually understand.
> Where does this struct get initialized?
> 
> Any help on this one would be most appreciated as that will put a stop
> on me pulling my hairs out :-)
> 
> Best wishes,
> 
> Ico
> 
> 
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list



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

[PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)

[Ivica Ico Bukvic]

Dear fellow Pd enthusiasts,

I am pleased to report that earlier today L2Ork released latest snapshot
of its own variation of pd-extended 0.42.5. While we are working hard on
submitting isolated patches upstream (some of which have been already
submitted), many more need to be isolated before they can be provided in
a useful format. Another roadblock is that we are still stuck on 0.42.5
which makes patch integration so much more difficult into the 0.43
branch.

That said, we would love to get some feedback/testers. The tarball is
for *linux only* clients (a good number of optimizations have not been
tested on other platforms and there are already known issues,
particularly in respect to pd.tk file).

Some of the notable improvements include much faster editor (instead of
redrawing we tag and move objects wherever possible while still allowing
for legacy movement of objects not conforming to the pd vanilla
gobj_displace format), bunch of usability improvements (e.g. custom
color picker with color storing and hex editing), per-canvas toggling of
menu and background color (see Abstractions), universal shortcuts,
different scrolling algorithm. Likewise, the UI is entirely revamped to
better fit the "Gnome-ish" feel. Jack connectivity algorithm also is
automated and compensates for changes in srate, etc.

At any rate, there are bunch of other little/big fixes I honestly cannot
recall. These improvements are a product of a year of use within the
context of a 15-member laptop orchestra taking into an account feedback
from students/participants, including also my latest hac-a-thon this
past week that involved overhauling redraw to improve editor speed. So,
if any of you would be so kind as to give it a stab and provide any
feedback, that would be most appreciated.

You can get the latest snapshot from
http://l2ork.music.vt.edu/main/?page_id=56

The source tarball also includes prebuilt binaries, so assuming you have
an intel machine with Ubuntu 9.10, it should "just run." (cd pd/bin/
followed by ./pd). Otherwise, you may have to rebuild it (standard
pd-extended 0.42.x procedure).

Your feedback, particularly bug-reports are most appreciated.

Best wishes,

Ico


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

Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)

[Ivica Ico Bukvic]

Since there are prebuilt binaries and therefore platform-specific
configs, probably the safest thing you need to do to rebuild on your
platform from scratch is to do the following:

cd pd/src
make distclean
aclocal
autoconf
./configure (with flags you wish to use, typically --prefix=/usr
--enable-jack --enable-alsa)
make
cp pd.tk ../bin (old stale one crept into the tarball inside the bin
directory--I will fix this shortly and reupload the tarball)

at that point you can either:
cd ../bin
./pd

or (if you feel like this version is worthy being installed system-wide)
make install
pd

NB: pre-built binaries are for i386 arch only so they are unlikely to
work on other (e.g. 64-bit Linux).

As for swapping pd.tk alone, this won't work as pd.tk depends on changes
to the source as well.

Finally, regarding the scrolling algorithm, the new version updates
scrollbars once a key has been released or mouse has stopped dragging.
This is because on an Atom netbook (what we use in L2Ork) things got
bogged down quite quickly when using continual scrollbar updates. If you
wish to try that one out (it also uses old object moving code via
"coords" call which is a lot less efficient) simply download the
20101117 version (replace 20101120 in the URL of the current one).

HTH

Best wishes,

Ico

On Sun, 2010-11-21 at 11:50 +, ALAN BROOKER wrote:
> 
> Hi Ico,
> 
> 
> 
> I'm on Ubuntu and have tried to ./configure but the terminal reports
> no tk library found :
> 
> 
> 
> checking for tcl8.4/tcl.h... yes
> 
> checking for main in -ltcl85... no
> 
> checking for main in -ltcl8.5... no
> 
> checking for main in -ltcl84... no
> 
> checking for main in -ltcl8.4... yes
> 
> checking for main in -ltk85... no
> 
> checking for main in -ltk8.5... no
> 
> checking for main in -ltk84... no
> 
> checking for main in -ltk8.4... no
> 
> checking for main in -ltk8.3... no
> 
> checking for main in -ltk8.2... no
> 
> checking for main in -ltk8.0... no
> 
> no tk library found
> 
> 
> 
> 
> and further make errors:
> 
> 
> 
> 
> ldl -lm -lpthread -lasound
> 
> /usr/bin/ld: cannot find -lasound
> 
> collect2: ld returned 1 exit status
> 
> make: *** [../bin/pd] Error 1
> 
> 
> 
> 
> 
> 
> Still wanting to check it out I swapped the pd-extended pd.tk file
> with the one from L2Ork pd.tk file and I am getting the following
> errors on a pop up:
> 
> 
> can't read "mult": no such variable
> 
> can't read "mult": no such variable
> 
> while executing
> 
> "expr int($height / ($mult * 2))"
> 
> ("text" arm line 36)
> 
> invoked from within
> 
> "switch -exact [$name type $item] {
> 
> "arc" -
> 
> "line" -
> 
> "oval" -
> 
> "polygon" -
> 
> "rectangle" {
> 
> set coords [$name coords $item]
> 
> foreach ..."
> 
> (procedure "pdtk_canvas_getscroll" line 38)
> 
> invoked from within
> 
> "pdtk_canvas_getscroll $name"
> 
> (procedure "pdtk_canvas_getscroll_ping" line 9)
> 
> invoked from within
> 
> "pdtk_canvas_getscroll_ping .xa5b7038.c"
> 
> ("after" script)
> 
> 
> And sometimes there are no up scrolling bars
> 
> 
> But I wish to say the improvements to the gui on Ubuntu are really
> nice! Really want to use this from now on- the larger “cord/wire
> connect” icon is really useful- and appreciate any feedback regarding
> the above
> 
> 
> Cheers
> 
> 
> Al
> 
> On Sat, Nov 20, 2010 at 9:20 PM, Ivica Ico Bukvic  wrote:
> Dear fellow Pd enthusiasts,
> 
> I am pleased to report that earlier today L2Ork released
> latest snapshot
> of its own variation of pd-extended 0.42.5. While we are
> working hard on
> submitting isolated patches upstream (some of which have been
> already
> submitted), many more need to be isolated before they can be
> provided in
> a useful format. Another roadblock is that we are still stuck
> on 0.42.5
> which makes patch integration so much more difficult into the
> 0.43
> branch.
> 
> That said, we would love to get some feedback/testers. The
> tarball is
> for *linux only* clients (a good number of optimizations have
> not been
> tested on other platforms and there are already known issues,
> particularly in respect to pd.tk file).
> 
> Some of the notable improvements include much faster editor
> (instead of
>   

Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)

[Ivica Ico Bukvic]

> Also, forgot to mention in my original email this version AFAIK fixes
> all graph-on-parent bugs.

Just remembered a few more that some of you might find useful:

*send to back/bring to front right-click menu for those of you
interested in building more complex UIs
*auto-update of scrollbars when typing/resizing objects
*canvas always tries to fit the entire patch as best as it can (it is
not any more 0,0 coord-centric, however, so it will not reopen patches
the way they may have looked in the vanilla-version of pd)
*text editing has ctrl+home and ctrl+end traversal between
space-delimited words
*"select all" is context sensitive (so when editing an object select all
will select all its text rather than all objects on the canvas)
*select/cut/copy/paste is universal (works seamlessly across text fields
and canvas)
*commands are ignored in contexts where they have no purpose (e.g.
create an object shortcut invoked on the main canvas should have no
effect)
*improved accuracy of canvas reporting it has been changed

Cheers!

Best wishes,

Ico


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

Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)

[Ivica Ico Bukvic]

> I also had trouble with the tk dependency. When I tried to run the
> pre-built binary in the tarball it said it couldn't find
> libtk8.5.so.0, even though it is present in /usr/lib. I'm running
> Ubuntu Maverick.
> 
> -spencer

Could you please try rebuilding using steps I sent out in reply to
Alan's inquiry and let me know if that works?

Also, forgot to mention in my original email this version AFAIK fixes
all graph-on-parent bugs.

Best wishes,

Ico



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

Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)

[Ivica Ico Bukvic]

> But I wish to say the improvements to the gui on Ubuntu are really
> nice! Really want to use this from now on- the larger “cord/wire
> connect” icon is really useful- and appreciate any feedback regarding
> the above

Just to clarify, this appearance is not our addition but this is already
a part of the "vanilla" pd-extended, so this is largely thanks to the
hard work of Hans et al.

Best wishes,

Ico


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

Re: [PD] Trying to track a ghost pdtk_canvas_getscroll call

[Ivica Ico Bukvic]

Hi Mathieu,

This is a great advice! However, when adding blargh() function from the
gridflow.c inside the sys_vgui (s_inter.c) so that when the debug is on
it outptus a trace for each call, it appears it only manages to do one
level which is obviously the sys_vgui call itself. Why is it not able to
trace further back?

void blargh(void) {
#ifdef MACOSX
  fprintf(stderr,"unhandled exception\n");
#else
  int i;
  void *array[25];
  int nSize = backtrace(array, 25);
  char **symbols = backtrace_symbols(array, nSize);
  for (i=0; i

if (sys_debuglevel & DEBUG_MESSUP) {
blargh();
fprintf(stderr, "%s",  sys_guibuf + sys_guibufhead);
}



}


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

Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)

[Ivica Ico Bukvic]

Ugh, forgot to mention another critical thing--this version requires tcl/tl 8.5 
or higher.

Best wishes,

Ico

Ivica Ico Bukvic  wrote:

>
>> Also, forgot to mention in my original email this version AFAIK fixes
>> all graph-on-parent bugs.
>
>Just remembered a few more that some of you might find useful:
>
>*send to back/bring to front right-click menu for those of you
>interested in building more complex UIs
>*auto-update of scrollbars when typing/resizing objects
>*canvas always tries to fit the entire patch as best as it can (it is
>not any more 0,0 coord-centric, however, so it will not reopen patches
>the way they may have looked in the vanilla-version of pd)
>*text editing has ctrl+home and ctrl+end traversal between
>space-delimited words
>*"select all" is context sensitive (so when editing an object select all
>will select all its text rather than all objects on the canvas)
>*select/cut/copy/paste is universal (works seamlessly across text fields
>and canvas)
>*commands are ignored in contexts where they have no purpose (e.g.
>create an object shortcut invoked on the main canvas should have no
>effect)
>*improved accuracy of canvas reporting it has been changed
>
>Cheers!
>
>Best wishes,
>
>Ico
>
>
>___
>Pd-list@iem.at mailing list
>UNSUBSCRIBE and account-management -> 
>http://lists.puredata.info/listinfo/pd-list
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Trying to track a ghost pdtk_canvas_getscroll call

[Ivica Ico Bukvic]

Unfortunately I do not see myself migrating to the new version until it is as 
stable as the one we currently use.

Hans-Christoph Steiner  wrote:

>
>Before you invest too much time in that, you should know that that  
>stuff has changed a lot in 0.43, so its likely anything you did in  
>0.42 would not apply to 0.43
>
>.hc
>
>On Nov 21, 2010, at 10:40 AM, Ivica Ico Bukvic wrote:
>
>> Hi Mathieu,
>>
>> This is a great advice! However, when adding blargh() function from  
>> the
>> gridflow.c inside the sys_vgui (s_inter.c) so that when the debug is  
>> on
>> it outptus a trace for each call, it appears it only manages to do one
>> level which is obviously the sys_vgui call itself. Why is it not  
>> able to
>> trace further back?
>>
>> void blargh(void) {
>> #ifdef MACOSX
>>  fprintf(stderr,"unhandled exception\n");
>> #else
>>  int i;
>>  void *array[25];
>>  int nSize = backtrace(array, 25);
>>  char **symbols = backtrace_symbols(array, nSize);
>>  for (i=0; i>  free(symbols);
>> #endif
>> }
>>
>> void sys_vgui(char *fmt, ...)
>> {
>>
>> 
>>
>>if (sys_debuglevel & DEBUG_MESSUP) {
>>  blargh();
>>fprintf(stderr, "%s",  sys_guibuf + sys_guibufhead);
>>  }
>>
>> 
>>
>> }
>>
>
>
>
>
>"A cellphone to me is just an opportunity to be irritated wherever you  
>are." - Linus Torvalds
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)

[Ivica Ico Bukvic]

The front/back option works on as many selected objects as you like. Simply 
select objects you wish to be moved, right click, and then select the desired 
action. That said I do agree that it would be probably a good idea to also have 
a keyboard shortcut and place them in the menu.

Jonathan Wilkes  wrote:

>One comment about bring to front/send to back:
>* I think I'd rather see this as "Edit" menu options that work on 
>all selected objects, rather than per object.  This would be more 
>useful for those situations where people are building complex GUIs.  
>(And if necessary it could have a keyboard shortcut.)
>This would allow the right-click menu to retain its simplicity 
>of having only those three options that are of general use to the 
>user.  (I think bring to front/send to back is a wonderful feature 
>but it's definitely way more specialized than getting help, 
>GUI properties, or opening a subpatch).
>
>One thing I'm noticing about the new connection icon:  if I point the 
>mouse over an outlet and then move the mouse about 20-40 pixels to 
>the right, the connection icon remains even though it won't spawn a 
>wire if I click and drag.
>
>-Jonathan
>
>--- On Sun, 11/21/10, Ivica Ico Bukvic  wrote:
>
>> From: Ivica Ico Bukvic 
>> Subject: Re: [PD] call for testers for L2Ork iteration of pd-extended (based 
>> on 0.42.x branch)
>> To: Pd-list@iem.at
>> Date: Sunday, November 21, 2010, 4:52 PM
>> 
>> > Also, forgot to mention in my original email this
>> version AFAIK fixes
>> > all graph-on-parent bugs.
>> 
>> Just remembered a few more that some of you might find
>> useful:
>> 
>> *send to back/bring to front right-click menu for those of
>> you
>> interested in building more complex UIs
>> *auto-update of scrollbars when typing/resizing objects
>> *canvas always tries to fit the entire patch as best as it
>> can (it is
>> not any more 0,0 coord-centric, however, so it will not
>> reopen patches
>> the way they may have looked in the vanilla-version of pd)
>> *text editing has ctrl+home and ctrl+end traversal between
>> space-delimited words
>> *"select all" is context sensitive (so when editing an
>> object select all
>> will select all its text rather than all objects on the
>> canvas)
>> *select/cut/copy/paste is universal (works seamlessly
>> across text fields
>> and canvas)
>> *commands are ignored in contexts where they have no
>> purpose (e.g.
>> create an object shortcut invoked on the main canvas should
>> have no
>> effect)
>> *improved accuracy of canvas reporting it has been changed
>> 
>> Cheers!
>> 
>> Best wishes,
>> 
>> Ico
>> 
>> 
>> ___
>> Pd-list@iem.at
>> mailing list
>> UNSUBSCRIBE and account-management -> 
>> http://lists.puredata.info/listinfo/pd-list
>> 
>
>
>  
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)

[Ivica Ico Bukvic]

> -Original Message-
> From: Menno van der Woude [mailto:menn...@gmail.com]
> Sent: Sunday, November 21, 2010 5:21 PM
> To: Ivica Ico Bukvic
> Cc: Pd-list@iem.at
> Subject: Re: [PD] call for testers for L2Ork iteration of pd-extended (based
> on 0.42.x branch)
> 
> To solve the problem with the tk library, I had to install package
> "tk-dev". Same for tcl, installed package "tcl8.5-dev". After
> installing these packages I I was able to complete the build process
> specified in the email (not as is written in the INSTALL text file in
> the tarball). Now this pd version starts with no problems. Sound
> works, using Alsa. I did "./configure --enable-jack", but jack is not
> available in the audio menu.
> Have not yet had time to look further into functionality. Did notice
> that using the send to back/bring to front functionality (which is
> nice!) does reset all the visual controls in a patch.

You need yo also install jack-dev to be able to install with jack. Monitor 
./configure output to learn what you are missing.


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

Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)

[Ivica Ico Bukvic]

> Attached is another example:
> 1. Select all the [clip] objects.
> 2. Move them so the [vsl] overlaps them.
> 3. Right-click the bottom [clip] and choose "To front". It works as 
> it should.
> 4. Now, with all the [clip] objects still selected, right-click on 
> the same bottom [clip] and choose "To back".  It deselects all the 
> other clips and only moves the bottom [clip] to the back.  But 
> shouldn't it instead move all the selected objects behind the 
> [vsl]?

You are correct. Just fixed this bug, changed the edit menu ordering and
included to front/back options, added key shortcuts, added tidy up
shortcut and increased its threshold which IMHO makes it much more
usable.

HTH


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

Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)

[Ivica Ico Bukvic]

> Regarding "tidy up"-- are you referring to XTOLERANCE,
> YTOLERANCE, and NHIST?  If so, I posted a message awhile back with

I set it to 20 20 15 respectively and it seems to do the trick in tests I did 
so far.

> what seemed like some decent values, but in some cases it would
> swap the position of two objects in a row or column.  Also, this
> behavior changed depending on the order in which those objects were
> created.  (I have a feeling this is why those values are set so low.)
> 
> If you post another tar.gz with your new "tidy" I'll see
> if I can reproduce this behavior.

Oops, forgot to post this one, haven't I? :-)

Same place, same links:

http://l2ork.music.vt.edu/main/?page_id=56

HTH

Best wishes,

Ico
 


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

Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)

[Ivica Ico Bukvic]

It appears your also missing tk dev libraries

ALAN BROOKER  wrote:

> Hi Ico
>
>cd pd/src
>
>make distclean
>aclocal
>autoconf
>./configure (with flags you wish to use, typically --prefix=/usr
>--enable-jack --enable-alsa)
>make
>cp pd.tk ../bin (old stale one crept into the tarball inside the bin
>directory--I will fix this shortly and reupload the tarball)
>
>at that point you can either:
>cd ../bin
>./pd
>
>or (if you feel like this version is worthy being installed system-wide)
>make install
>pd
>
>
> I have gotten further with compiling but I do get the following error at
>make install:
>
>t_main.c
>
>t_main.c:18:16: error: tk.h: No such file or directory
>
>t_main.c:38: error: expected ‘)’ before ‘*’ token
>
>t_main.c: In function ‘main’:
>
>t_main.c:59: warning: implicit declaration of function ‘Tk_Main’
>
>t_main.c:59: error: ‘Tcl_AppInit’ undeclared (first use in this function)
>
>t_main.c:59: error: (Each undeclared identifier is reported only once
>
>t_main.c:59: error: for each function it appears in.)
>
>t_main.c: At top level:
>
>t_main.c:86: warning: function declaration isn’t a prototype
>
>t_main.c: In function ‘Tcl_AppInit’:
>
>t_main.c:86: error: expected declaration specifiers before ‘Tcl_Interp’
>
>t_main.c:85: warning: type of ‘interp’ defaults to ‘int’
>
>t_main.c:88: error: ‘Tk_Window’ undeclared (first use in this function)
>
>t_main.c:88: error: expected ‘;’ before ‘mainwindow’
>
>t_main.c:90: warning: implicit declaration of function ‘Tcl_Init’
>
>t_main.c:90: error: ‘TCL_ERROR’ undeclared (first use in this function)
>
>t_main.c:93: warning: implicit declaration of function ‘Tk_Init’
>
>t_main.c:99: warning: implicit declaration of function ‘pdgui_startup’
>
>t_main.c:112: error: ‘TCL_OK’ undeclared (first use in this function)
>
>make: *** [t_main.o] Error 1
>
>
>
>
> Thanks for any tips-almost got it going
>
>
>
>On Tue, Nov 23, 2010 at 8:37 AM, João Pais  wrote:
>
>> Hi,
>>
>> this sounds great. I might have a chance to try it next week (back to dsl),
>> if I have a break. But some questions in advance:
>>
>> - is there a "release program"? are the testers to make sure the
>> implementations are working well, or do you still take requests?
>>
>> - what is going to happen to all this work, hopefully be integrated in
>> pd-van/ext?
>>
>> - will someone put the code to work in all systems? (especially windows)
>>
>> - will you/your team continue to make improvements here (there are really
>> lots of things that can be done), or was this a one-off project?
>>
>> - is there a feature list, to know how to test the novelties?
>>
>> - did you look at ? in an informal presentation here one of their
>> developers said that he was inspired by pd, but added lots of details that
>> make the user experience much faster and easier, sometimes just by
>> implementing small details (let the mouse over an outlet to see the values,
>> etc.).
>>
>>
>> Best,
>>
>> João
>>
>>
>> ___
>> Pd-list@iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)

[Ivica Ico Bukvic]

> - is there a "release program"? are the testers to make sure the
> implementations are working well, or do you still take requests?

Not only requests but also active contributions are very much welcome. Ideally, 
patches provided would be both pd vanilla and our pd-compatible, so that 
theoretically everyone can benefit.

> - what is going to happen to all this work, hopefully be integrated in
> pd-van/ext?

I've tried sending over dozen patches upstream over the past year (and there 
are at least another half-dozen I need to submit). While some have made it into 
vanilla Pd, many of them haven't. I think partially because most of the core 
devs are plugging away at 0.43 which for me is a no go as of right now as I 
need something that is as production-ready and bug-free as possible. Other 
reasons include possibly the fact that some of the patches may be seen as 
controversial in terms of how they tackle issues. E.g. scrolling algorithm 
fundamentally changes how canvas spatial context is being calculated and as 
such it may take some time to adjust to.

Tldr; While I hope all patches I've submitted do make it upstream, I have no 
way of knowing. 0.43 will get there and possibly soon but I don't feel 
comfortable running it yet.

> 
> - will someone put the code to work in all systems? (especially windows)

That someone would have to be someone else than me as I am swamped as it is and 
quite frankly other OSs are not (and will likely never be) a priority in L2Ork. 
That said, I will gladly merge whatever improvements I can get in this respect. 
We've already put a decent amount of work inside pd.tk to allow better 
separation of Linux from other Oss in terms of customizations but it has not 
been consistent throughout, so it is a simple matter of tracking those 
inconsistencies down and adjusting accordingly.

> 
> - will you/your team continue to make improvements here (there are
> really
> lots of things that can be done), or was this a one-off project?

As best as we can. At this point it is mainly me and occasionally I get some 
student help.

> 
> - is there a feature list, to know how to test the novelties?

I should've done a laundry list of these as I went but somewhere along the road 
I lost track so honestly I don't know just how many fixes are there. That said, 
I am quite sure there easily dozens upon dozens of them in this release alone.

> 
> - did you look at ? in an informal presentation here one of their
> developers said that he was inspired by pd, but added lots of details that
> make the user experience much faster and easier, sometimes just by
> implementing small details (let the mouse over an outlet to see the
> values, etc.).

I saw it briefly and I agree there are a lot of options that could be added. I 
think the important question which ones should be given greatest priority.

e.g. I am right now thinking it would be nice to have resizable cnv just by 
clicking on its bottom-right corner. Ditto for other visual iemgui objects. 
Another thing I would really like to see soon is ability to box-select patch 
cords. Then perhaps an undo doubly-linked list would be nice as well (although 
not sure how hard this would be).

HTH

Best wishes,

Ico

> 
> 
> Best,
> 
> João


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

Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)

[Ivica Ico Bukvic]

> Ok, this is looking familiar-- have a look at tidy-test.pd, select 
> each group of objects one at a time and do 'tidy up':
> 1. Works as it should.
> 2. Objects are below the y-threshold, so they (understandably) 
> collapse.
> 3. Works as it should.
> 4. Objects spaced 30 px apart vertically seem arbitrarily to no 
> longer get tidy.
> 5. Horizontal row of objects gets tidy (with arbitrarily large space 
> in between any two objects).  Works as it should-- columns of objects 
> should behave the same way.
> 
> Now select all and tidy.  Notice that #3 now gives different results.
> 
> -Jonathan

Interesting... It seems to me tidy would work better if it simply
checked first if it had objects that are vertically or horizontally
closer to its x,y position and then adjust according to them only,
rather than keeping a HIST of values it may be able to potentially
adjust to. This would of course require change to the algorithm's
fundamentals. Another thought would be to have the whole thing keep
running with ever-increasing thresholds until something is adjusted or
some ridiculous threshold is reached.

Ico


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

Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)

[Ivica Ico Bukvic]

> Thanks Ico, it's working now- no errors- 
> 
> 
> Really sorry to be a pain but can I ask how I can easily point pd to
> pick up my libraries, Gem etc, other than inputting the folders  and
> binary names one by one from start up & paths menu?
> 
> 
> Thanks again !
> Al

Assuming you've been using pd-extended, easiest is to copy
default.pdsettings (the one we have on the L2Ork site) and copy it to
your /usr/lib/pd folder. You may want to back your old one up before
doing so if you have custom settings in there already.

Second easiest is to install pd-extended dpkg for your distro (ideally
the one before its executable and path have been moved
to /usr/lib/pd-extended, which is I believe 0.42.5 snapshot from a
couple months ago) and then reinstall L2Ork's version over it and copy
the aforesaid default.pdsettings file.

HTH

Ico





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

Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)

[Ivica Ico Bukvic]

> > Perhaps you'd be interested in my unreleased tkwidgets library, its  
> > in SVN.  Basically, I am working on creating a framework to make it  
> > much easier to make GUI objects. Part of that framework includes  
> > things like resizing things with the mouse.  I have that much  
> > working but its buggy still.  Once that gets ironed out, I plan on  
> > making Pd versions of all the core Tk widgets, including the Tk  
> > canvas.  In tkwdigets there is already a [text] object that works  
> > quite nicely, save a few bugs.
> 
> I forgot to add, my experience with the iemgui code has told me that  
> they would be very difficult to improve, hence the tkwidgets lib.

Unfortunately, if it is not finished/stable, I am not interested in it
as having to deal with Pd bugs in and of themselves is demanding enough
on my time. On a flip side Scope~ external already has similar
functionality which seems to me quite complete so it may be simply a
matter of implementing that one (obviously it would only apply to iemgui
objects as vanilla objects have no way of knowing their own size).

That said, I did spend most of today implementing Sarlo's feature as
well as fixing buggy Tcl/Tk behavior (namely inability to show check
marks in the edit menu which is so disheartening it is not even funny--I
really think Pd needs to wean itself away from the Tcl/Tk abomination
even if that means losing a good chunk of its externals before it can
thrive).

NB: I left out "drop shadows" part as it seems quite redundant. I also
changed how the rest of the code behaves/looks to make it visually
cleaner/more consistent.

Apart from that latest update also includes edit menu highlighting (as
0.43 does to bypass Tcl/Tk buggy junk), improved shortucts for some of
the calls, bugfix in the window list menu which for some reason omits
parent window listing, and other minor cosmetic fixes (e.g. highlighting
color changed to orange as I feel it is much easier on my eyes).

If interested, check out the latest snapshot at the usual place:

http://l2ork.music.vt.edu/main/?page_id=56

Cheers!



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

Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)

[Ivica Ico Bukvic]

> Notice that both [cyclone/Scope~] and [flatspace/entry] have a
> bug: a sudden increase in height/width by about 5-10 pixels when you
> initially drag to resize.  This makes it difficult if not
> impossible to make minor size changes (especially since there is no
> Properties dialogue).

Good to know. I will look into this when I get there. Currently working on 
accelerating iemgui objects as well as exposing them to sarlo's highlighting 
magic.

> Wouldn't it be easier just to toggle the text for that menu option
> between "Edit mode" and "Run mode"? (That's what they're called in
> the manual.)

Sure. There are other options, too, like the one 0.43 and now l2ork version of 
0.42 uses by changing option's background which works visually relatively well 
(albeit at the expense of consistency). This is however not the issue. The 
issue is finding out that after an hour of debugging the problem is not in you 
or your code but the toolkit you are using and in 2010 for a toolkit that has 
been around for more than a decade that is plainly sad.

> How would you go about doing that?

A: Ugly path: Isolate pd<->gui hooks and port the entire thing to Qt.

B: Better (albeit more time-consuming) path: clean-up code first so that all 
objects can utilize the same gobj_ calls and then do the A: (which at 
that point won't be nearly as ugly or difficult to maintain).

FWIW, my first ever GUI app was RTMix I did back in 2001 and it was (and 
remains) the ugliest hack ever (basically I tried to learn how to program doing 
that app). Yet, the fact remains even in 2001 qt was way better than what Tk is 
today. Another advantage is avoiding socket bottlenecks as the entire thing 
could be done simply in C. License-wise it should be fine and 
cross-platform-wise miles ahead of Tcl/Tk. Heck, you could even throw in Qt for 
mobile devices for good measure since that is apparently hot item these days.

That said, I need some more time working with Pd code before I can undertake 
this. Perhaps more importantly, I just need a generous, uninterrupted chunk of 
time to do this.

Best wishes,

Ico 


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

Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)

[Ivica Ico Bukvic]

Unfortunately not at this point in time as I've not tested my stuff with
gridflow at all yet (it is on my TODO). Perhaps Mathieu might have some
suggestions? Mathieu, AFAIK in l2ork iteration of pd-extended the only
thing that changed fundamentally pd-wide is widgetbehavior got another
entry at the end.

BTW, this may seem a bit of a silly question but just to be safe, you
did try the same gridflow lib with the regular vanilla pd you used prior
to l2ork iteration and if so did it work there?

Cheers!

On Wed, 2010-11-24 at 16:39 +, ALAN BROOKER wrote:
> Okay- I've traced to Gridflow library- I've taken it out and no
> crashes -any tips how I can have it installed would be appreciated-
> thanks again for your time on this :)
> 
> On Wed, Nov 24, 2010 at 12:57 PM, Ivica Ico Bukvic  wrote:
> Try loading one lib at a time and doing the same. I don't know
> for sure but it might be that one or more of them is having
> issues with the new move algorithm.
> 
> 
> ALAN BROOKER  wrote:
> 
> >Hi Just to clarify the message
> >Program received signal SIGSEGV, Segmentation fault.
> >0x0011 in ?? ()
> >
> >is printed on the terminal when ctrl-1 is used
> >
> >Thanks again
> >On Wed, Nov 24, 2010 at 10:11 AM, ALAN BROOKER
> >wrote:
> >
> >> Hi Ico
> >>
> >>
> >> Ive got it working and have loaded some libraries, Gem,
> Gridflow, Zexy, pdp
> >> - however PD crashes out when I ctrl-1 to put an object on
> the canvas.
> >>
> >> I've done a backtrace (thanks Mathieu for the tip
> previously) with the
> >> following results:
> >>
> >> Starting program: /usr/local/bin/pd -oss -channels 2
> my-bug-test.pd
> >> [Thread debugging using libthread_db enabled]
> >>  : Avifile
> RELEASE-0.7.48-100119-21:44-../src/configure
> >>  : Available CPU flags: fpu vme de pse tsc msr pae
> mce cx8 apic mtrr
> >> pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall
> nx mmxext
> >> fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc
> nonstop_tsc extd_api
> >>  : 800.00 MHz AMD Phenom(tm) II X2 555 Processor
> detected
> >> [New Thread 0xb47e1b70 (LWP 4084)]
> >>
> >> Program received signal SIGSEGV, Segmentation fault.
> >> 0x0011 in ?? ()
> >> (gdb) where
> >> #0  0x0011 in ?? ()
> >> #1  0x080a94d5 in gobj_displace_withtag (x=0x8206cb8,
> >> dx=, dy=0) at g_editor.c:68
> >> #2  canvas_displaceselection (x=0x8206cb8, dx= optimised out>, dy=0)
> >> at g_editor.c:1900
> >> #3  0x080a98a5 in canvas_motion (x=0x8206cb8, xpos=232,
> ypos=76, fmod=2)
> >> at g_editor.c:2089
> >> #4  0x080ca4f6 in pd_typedmess (x=0x8206cb8, s=0x8135eb8,
> argc=3,
> >> argv=0xb08c) at m_class.c:792
> >> #5  0x080ca0dc in pd_typedmess (x=0x814ac60, s=0x8135eb8,
> argc=3,
> >> argv=0xb08c) at m_class.c:813
> >> #6  0x080cfbaa in binbuf_eval (x=0x8149688, target= optimised out>,
> >> argc=0, argv=0x0) at m_binbuf.c:726
> >> #7  0x080dde5f in socketreceiver_read (x=0x81496a8, fd=6)
> at s_inter.c:560
> >> #8  0x080dd81a in sys_domicrosleep (microsec= optimised out>,
> >> pollem=) at s_inter.c:198
> >> #9  0x080de502 in sys_pollgui () at s_inter.c:862
> >> #10 0x080d9321 in m_pollingscheduler () at m_sched.c:490
> >> #11 m_mainloop () at m_sched.c:560
> >> #12 0x080dc8a9 in sys_main (argc=5, argv=0xb4e4) at
> s_main.c:310
> >> #13 0x080e556b in main (argc=5, argv=0xb4e4) at
> s_entry.c:32
> >> (gdb)  quit
> >> A debugging session is active.
> >>
> >> Inferior 1 [process 4078] will be killed.
> >>
> >> Quit anyway? (y or n) y
> >> socket receive error: Connection reset by peer (104)
> >>
> >> Thanks for your help with this! It's a great package to
> work from
> >> Che

Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)

[Ivica Ico Bukvic]

OK, latest snapshot 20101124 has been just made available in the usual
place with additional improvements including:

*all vanilla and iemgui objects are now "accelerated" in terms of their
redrawing and moving, resulting in a dramatic improvement in UI
responsiveness (for the devs, the new model uses tagging of widgets and
move command, rather than apparently a much more cpu expensive coords
call)

*sarlo's magic highlighter now works on all iem objects as well as gop
objects

*more cosmetic bug fixes

http://l2ork.music.vt.edu/main/?page_id=56

As always, feedback is most appreciated!

Best wishes,

Ico


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

Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)

[Ivica Ico Bukvic]

> I just realize that there are two iemgui libs in a sense: there are
> the iemgui objects that have been included in Pd-vanilla for 10 years,
> those are the ones I was referring to.  Then there is the new iemgui
> library in pure-data SVN, I know little about that one.  Which one are
> you referring to?

I am referring to the one that has been a part of pd for a long time. This is 
the one I just updated in the latest release so that moving of its widgets in 
edit mode is now a part of a single move-by-tag call. I am actually quite 
pleased how it works now.

> FYI, 0.43 fixes this issue by changing the 'editmode' message so that
> 1 means editmode is on, and 0 means editmode is off.  Before that, the
> 'editmode' message toggled edit mode.  That's what made it so
> difficult to make the menu item checkbox work.  These are the kinds of
> things that I have spent many many hours working to fix, so it makes
> me sad to see you reinventing the wheel.

I am not reinventing wheel in this case but simply backporting your solution 
(unless you are referring to me wasting hours as you did on the Tcl widget bug 
as the actual reinventing of the wheel). Either way, the checkmark next to the 
checkbutton widget is simply buggy and does not show up when it should (e.g. 
when invoking the widget). This is the case even with 0.43 gui rewrite. The 
only way one can "see" that the option has been activated on 0.43 (and now on 
l2ork iteration of 0.42) is by the fact "edit mode" option in the menu has 
changed its background color to green (which actually does not look all that 
bad, even though it is inconsistent with general menu UI guidelines Tcl/Tk is 
supposedly trying so hard to enforce).

> Peter Brinkmann, Peter Kirn, Miller and I all had a meeting recently
> to discuss the idea of making 'pd' a separate entity.  My part is
> making pd talk to pd-gui using pd messages, then it should be pretty
> straightforward to making new GUIs in lots of different toolkits.

As long as those messages are not something that needs to be sent via socket 
but can be also prototyped into direct function calls within C. Otherwise, the 
solution simply perpetuates the existing problem of socket and string parser 
saturation, resulting in very slow performance. Notice that even with l2ork 
iteration of pd-extended where everything "vanilla" now uses move-by-tag 
approach (in other words one call moves all selected widgets except for GOPs 
which are quite messy thus resulting in one call vs. potentially hundreds if 
not thousands) and which ostensibly approaches ideal performance via socket, it 
still gets relatively easily bogged down due to inherent overhead.

Best wishes,

Ico



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

Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)

[Ivica Ico Bukvic]

When installing onan arch other than i386 please make sure to do:

make distclean
aclocal
autoconf
./configure (with appropriate flags)
make

Etc.

HTH

Ico

András Murányi  wrote:

>On Wed, Nov 24, 2010 at 6:40 PM, Ivica Ico Bukvic  wrote:
>
>> OK, latest snapshot 20101124 has been just made available in the usual
>> place with additional improvements including:
>>
>> *all vanilla and iemgui objects are now "accelerated" in terms of their
>> redrawing and moving, resulting in a dramatic improvement in UI
>> responsiveness (for the devs, the new model uses tagging of widgets and
>> move command, rather than apparently a much more cpu expensive coords
>> call)
>>
>> *sarlo's magic highlighter now works on all iem objects as well as gop
>> objects
>>
>> *more cosmetic bug fixes
>>
>> http://l2ork.music.vt.edu/main/?page_id=56
>>
>> As always, feedback is most appreciated!
>>
>> Best wishes,
>>
>> Ico
>>
>>
>
>First i wish to say i had my doubts but now i'm happy to see an iteration of
>pd-extended in the wild. One may say there is some waste of time with a fork
>like this and of course there is, but it also proves pd-extended to be
>'adult' in a way and adults may have children, and children may seem to
>reinvent the wheel sometimes but that's all right and that's the way they
>can find their new, hopefully better ways. And meanwhile, hopefully, many
>thing will go upstream and it will be a big happy family :o) I'm
>particularly interested in better GUIs operating a well separated core, and
>happy to see Hans & Miller & al are advancing in this direction!
>
>
>I'm on AMD64 and has run into this with 'make':
>
>cd ../obj;  cc -Wl,-export-dynamic -lasound -lrt -ljack  -o ../bin/pd
>d_ctl.o d_array.o d_delay.o d_filter.o d_math.o d_osc.o d_soundfile.o
>g_canvas.o g_graph.o g_text.o g_rtext.o g_array.o g_template.o g_io.o
>g_scalar.o g_traversal.o g_guiconnect.o g_readwrite.o g_editor.o
>g_all_guis.o g_bang.o g_hdial.o g_hslider.o g_mycanvas.o g_numbox.o
>g_toggle.o g_vdial.o g_vslider.o g_vumeter.o g_magicglass.o m_pd.o m_class.o
>m_obj.o m_atom.o m_memory.o m_binbuf.o m_conf.o m_glob.o m_sched.o s_main.o
>s_inter.o s_file.o s_print.o s_loader.o s_path.o s_entry.o s_audio.o
>s_midi.o d_ugen.o d_arithmetic.o d_dac.o d_misc.o d_fft.o d_global.o
>d_resample.o x_arithmetic.o x_connective.o x_interface.o x_midi.o x_misc.o
>x_time.o x_acoustics.o x_net.o x_qlist.o x_gui.o x_list.o import.o
>s_midi_oss.o s_audio_oss.o s_audio_alsa.o s_audio_alsamm.o s_midi_alsa.o
>s_audio_jack.o d_fft_mayer.o d_fftroutine.o  -ldl -lm -lpthread -lasound
>collect2: ld terminated with signal 11 [Segmentation fault]
>/usr/bin/ld: i386 architecture of input file `d_ctl.o' is incompatible with
>i386:x86-64 output
>/usr/bin/ld: i386 architecture of input file `d_array.o' is incompatible
>with i386:x86-64 output
>/usr/bin/ld: i386 architecture of input file `d_delay.o' is incompatible
>with i386:x86-64 output
>/usr/bin/ld: i386 architecture of input file `d_filter.o' is incompatible
>with i386:x86-64 output
>/usr/bin/ld: i386 architecture of input file `d_math.o' is incompatible with
>i386:x86-64 output
>/usr/bin/ld: i386 architecture of input file `d_osc.o' is incompatible with
>i386:x86-64 output
>/usr/bin/ld: i386 architecture of input file `g_canvas.o' is incompatible
>with i386:x86-64 output
>/usr/bin/ld: i386 architecture of input file `g_graph.o' is incompatible
>with i386:x86-64 output
>/usr/bin/ld: i386 architecture of input file `g_text.o' is incompatible with
>i386:x86-64 output
>/usr/bin/ld: i386 architecture of input file `g_rtext.o' is incompatible
>with i386:x86-64 output
>/usr/bin/ld: i386 architecture of input file `g_array.o' is incompatible
>with i386:x86-64 output
>/usr/bin/ld: i386 architecture of input file `g_template.o' is incompatible
>with i386:x86-64 output
>/usr/bin/ld: i386 architecture of input file `g_io.o' is incompatible with
>i386:x86-64 output
>/usr/bin/ld: i386 architecture of input file `g_scalar.o' is incompatible
>with i386:x86-64 output
>/usr/bin/ld: i386 architecture of input file `g_traversal.o' is incompatible
>with i386:x86-64 output
>/usr/bin/ld: i386 architecture of input file `g_guiconnect.o' is
>incompatible with i386:x86-64 output
>/usr/bin/ld: i386 architecture of input file `g_readwrite.o' is incompatible
>with i386:x86-64 output
>/usr/bin/ld: i386 architecture of input file `g_editor.o' is incompatible
>with i386:x86-64 output
>/usr/bin/ld: i386 architecture of input file `g_vdial.o' is incompatibl

Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)

[Ivica Ico Bukvic]

On Thu, 2010-11-25 at 02:53 +0100, András Murányi wrote:
> moonlib indeed!
> 
> 2010/11/25 Jonathan Wilkes 
> [moonlib/mknob]
> 
> -Jonathan
> 
> Thanks, this worked.
> Now i'm having segfaults on patch load, it seems it's
> with [moocow/mknob].
> 

Confirmed. Looking into it...


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

Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)

[Ivica Ico Bukvic]

> Also notice that [flatspace/entry] has a nice cursor associated with 
> resizing.

Noted. I will look into this once bug hunt is over. Thanks for the tip!

> Another solution: you can also place a checkbutton labeled "Edit mode" 
> directly on the menubar.

Yes, except personally I would prefer to keep the pd window as clean as
possible.

> 
> Also, since we're talking about the menu changes: Since there is a "Find" 
> menu, I think the "Edit" menu can be shortened by removing "Find", "Find 
> again", and "Find last error".

Done. This will be included in the next tarball (even though it goes
against Msft/Apple design guidelines.

Best wishes,

Ico  



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

Re: [PD] magicglass WAS: call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)

[Ivica Ico Bukvic]

> And here's a little bug in the magicglass, in the attached patch, if you
> look at the cord beneath [list x.wav 44100(, it shows "x.wav 44100"
> which is different than "list x.wav 44100".

Thanks for the report, looking into it...


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

Re: [PD] magicglass WAS: call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)

[Ivica Ico Bukvic]

> (and a random aside, perhaps you'd be interested in getting Pd to use
> the GTK open panel?  I've always hated the Tcl/Tk one).

How would one go about doing this?


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