Hallo, Chris McCormick hat gesagt: // Chris McCormick wrote:

As the resident abstractions-over-externals obsessive, I feel I should put forward an argument to the contrary, just for good measure.

A speed comparison with a lua/python implementation would be interesting. You'd still be able to quickly change it or use it as a base for other objects without recompiling.

Ciao

Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:

Okay, I wrote a quick one using the markex code as a starting point. It would be interesting to benchmark this with Claude's patch against the pd-abstraction. (There's also a pdlua question for Claude hidden inside.)

Okay++: I benchmarked it, and Pd is slightly faster and I'm disappointed. ;)

Could this be because Lua calculates double precision? Maybe I'll benchmark again with LUA_NUMBER set to float.

Ciao

On Dec 11, 2007 10:35 AM, Frank Barknecht fbar@footils.org wrote:

Okay+++: With single precision, lua finally beats Pd and is about a fifth faster. I'm relieved, however that brings up the questions, if I should use lua with single precision in Pd? What would I loose (besides precision)?

For color data floating point is already overkill.

On Tue, 11 Dec 2007, chris clepper wrote:

On Dec 11, 2007 10:35 AM, Frank Barknecht fbar@footils.org wrote:

...

Okay+++: With single precision, lua finally beats Pd and is about a fifth faster. I'm relieved, however that brings up the questions, if I should use lua with single precision in Pd? What would I loose (besides precision)?

For color data floating point is already overkill.

One of PdConvention2007's papers talked about the use of floating-point with image data. It was the paper on FFT. For that case, it's not overkill, unless you consider a more complicated integer-based solution as not being overkill, which is something I'd dispute.

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada

BTW, if you're on an Intel machine, you can use LuaJIT to get a significant speed boost on looping structures and numerical calculations. wes

Well, Lua really shines for dynamic and generative systems. Try making dynamics graphics with polyphony in Pd and see how far you get. Things I wouldn't do _directly_ in Lua include video processing, DSP, etc. basically things with iterations over lots of data and intensive math ops. That said, I would still do them in Lua, but I would do them via C/C++ bindings that handle all of the really processing intensive work.

My basic approach to Lua is to use it as a sketching interface first and figure out how I want things to work and then once I get a feel for it, move certain sections down to C/C++. When you make this transition, it's best to generalize so that you can reuse it later. I do this for intensive operations like matrix processing, vector-ops, buffer drawing etc. First thing to do is get yourself some good vector math and quaternion bindings. I use these all the time and they save me a ton of work. I can send you a nice quaternion lib if you need it. Also, get yourself some mid-level OpenGL abstractions bound to Lua as userdata like Textures, Shaders, FBOs, etc that handle all of the dirty work under the hood and provide a clean interface to Lua. For example, here's some render-to-texture and post processing code as I typically use it in my own code:

local scene = Texture(1024, 768) local blurred_scene = Texture(1024, 768) local slab = Slab("blur.glsl") slab:param("width", {2, 2})

scene:begincapture(0) //draw scene here scene:endcapture(0)

slab:draw(scene, blurred_scene)

blurred_scene:bind(0) gl.Begin("QUADS") //draw a quad with tex coords gl.End() blurred_scene:unbind(0)

So, using a few higher-level C++ objects, you make make really concise scripts that do quite a bit. As you can see, it's really simple to render to a texture and apply effects to it given a representation of a Texture and a Slab. What's nice is that the slabs and can be arbitrarily chained together for more complicated effects and feedback with delay lines of varying length. The code for doing this stuff should be ready to share come the new year.

Taking this method to the extreme a friend of mine has made a scriptable DSP system using Lua called Vessel which is bundled into the Lua~ max external. The source is available and could easily be built into a pd external. See: http://www.mat.ucsb.edu/%7Ewakefield/lua%7E/lua%7E.htm .

If you're interested in discussing Lua for audiovisual composition, we've established a mailing list on the Media Arts and Technology servers here at UC Santa Barbara called lua-av ( http://zydeco.mat.ucsb.edu/mailman/listinfo/lua-av ). Feel free to sign up. There's very little traffic on it right now, but then again there are only about 5 people on the list. I don't think there are that many people doing audiovisual work with Lua right now anyway, but I anticipate more traffic once we get our standalone Lua-av software released and the utility of Lua for this kind of thing becomes apparent beyond the gaming industry. Most of the discussions about Lua and OpenGL right now are on the Jitter mailing list and it would be nice to consolidate these discussions into a central location that isn't Jitter, GEM, etc. specific.

best, wes

I've seen this while browsing the lua~ page. Unfortunatly the license of the underlying synz lib you are using is not compatible with pdlua in requiring written consent of the original author. synz may be compatible with a non-GPL pdlua, but I'd prefer a real open source library.

Ah, I've asked the author to reconsider the license. I'll get back to you on that. wes

please frank, keep lua discussion also on the pd list! everything so far was really related to pd, and is important to know. marius.

Frank Barknecht wrote:

Hallo, Wesley Smith hat gesagt: // Wesley Smith wrote:

...

Taking this method to the extreme a friend of mine has made a scriptable DSP system using Lua called Vessel which is bundled into the Lua~ max external. The source is available and could easily be built into a pd external. See: http://www.mat.ucsb.edu/%7Ewakefield/lua%7E/lua%7E.htm .

I've seen this while browsing the lua~ page. Unfortunatly the license of the underlying synz lib you are using is not compatible with pdlua in requiring written consent of the original author. synz may be compatible with a non-GPL pdlua, but I'd prefer a real open source library.

Anyway, thanks for all your inspiring remarks. I'll go subscribe to lua-av - if alone to not get on the nerves of Pd and Gem people with Lua stuff too much. ;)

Ciao

Well, Lua really shines for dynamic and generative systems. Try making dynamics graphics with polyphony in Pd and see how far you get. Things I wouldn't do _directly_ in Lua include video processing, DSP, etc. basically things with iterations over lots of data and intensive math ops. That said, I would still do them in Lua, but I would do them via C/C++ bindings that handle all of the really processing intensive work.

My basic approach to Lua is to use it as a sketching interface first and figure out how I want things to work and then once I get a feel for it, move certain sections down to C/C++. When you make this transition, it's best to generalize so that you can reuse it later. I do this for intensive operations like matrix processing, vector-ops, buffer drawing etc. First thing to do is get yourself some good vector math and quaternion bindings. I use these all the time and they save me a ton of work. I can send you a nice quaternion lib if you need it. Also, get yourself some mid-level OpenGL abstractions bound to Lua as userdata like Textures, Shaders, FBOs, etc that handle all of the dirty work under the hood and provide a clean interface to Lua.

This is essentially what I do too. I think pd/lua is interesting as you can have 3 layers of abstraction. You have more choice of when to move a piece of functionality to a different layer depending on what you are doing. I think the general rule should be keep it as high level as possible, and if you have to make it lower level make it as generic as possible (as you say).

It can be a really subtle desicion though - for example in fluxus now I'm restricting the grunt work in C++ to the critical path (for speed), and using Scheme where I need a more powerful language for the heavy lifting (eg collada import). It's hard to come up with hard and fast rules for what should be where - but if you have decent abstraction you can change your mind (move things up and down) without adversely effecting users with incompatibility.

cheers,

dave

http://www.pawfal.org/dave/

On Tue, 11 Dec 2007, Chris McCormick wrote:

As the resident abstractions-over-externals obsessive, I feel I should put forward an argument to the contrary, just for good measure. Basically it goes like this: CPU is getting cheaper, but programmer time is getting more expensive (or put a different way; i'd rather make the computer do work than myself do work).

The code for this is many years old and is small. The task to do does not change and the exact formulas are set. This is not the context in which one thinks about "programmer time getting more expensive".

My implication is that editing an abstraction is easier than editing & compiling an external, which could well be wrong, but there it is.

But why would you need to edit it?

But back to a more basic question: why do you want to use HSV ? it's that kind of weird hexagonal-pyramidal colourspace and that's one of the reasons why it's slower to process: you need to compute several "if" to get any value converted, and on modern processors, "if" is harder to optimise than anything else. But those same "if"s have other consequences: it makes the conversion formula bigger and somewhat harder to combine with other formulas. It's definitely not linear and not super close to any linear system.

if you do a polar transform on YUV, you have something easier, faster and more correct all at once. I usually just skip the polar transform: if you apply rotations directly on YUV values, you can make very believable hue shifts.

HSV is dubious in part because the apparent brightness at maximum so-called value is very variable and seems to peak high or low at secondaries or primaries: compare yellow (brightness 89%) and blue (brightness 11%). this really makes HSV suck sometimes. YUV does not have this problem.

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada

IOhannes m zmoelnig wrote:

Claude Heiland-Allen wrote:

...

Hi all,

Just wondering why hsv2rgb.pd (which is pretty incomprehensible) isn't a compiled external. I had to write a C implementation because the Pd implementation was too slow. Some rough benchmarks:

CPU: 1.6GHz Pentium-M Patch: rather complex, with 25*1024 calls to hsv2rgb per second. CPU-load as reported by load-meter.pd: hsv2rgb.pd : 108% fast_hsv2rgb.c : 94%

nop.pd : 94%

...

Quite a difference.

honestly i think that the difference is way less than i would have expected it.

The benchmark wasn't clean - the patch was doing a whole bunch of other stuff at the same time. See revised benchmark above, and see below for a clean benchmark:

hsv2rgb.pd : 26900 cputime (including test source) [1] fast_hsv2rgb.c : 6730 cputime (including test source) [2] no object : 5750 cputime (test source) [3]

([1]-[3]) / ([2]-[3]) gives 21.8

C is almost 22x (2200%) faster than the Pd implementation of hsv2rgb.

Claude