On Tue, 2004-06-08 at 16:32, Dave Phillips wrote: Why OpenGL? 3D display? What are the properties missing from existing implementations? -- Jussi Laako <jussi.laako(a)pp.inet.fi>

I like the idea of putting together a linux visualization system (maybe something more usable in a studio or in research than psychodelic effects). I remember the program that came with my first SGI machine. Coolest thing ever! I just 'gotta find a way to do something "different." Perhaps using the linux sound architecture is enough to get the project OK'ed. I'm pretty sure, though, that if I use enough precision, I could present it as a research tool... Or I could compute in parallel... ...and I get access to an SGI (linux SGI? Blasphemy. As much as I like linux, Irix is just....errrr...cute.) Thanks for all the ideas! --mike Nothing takes the taste out of peanut butter quite like unrequited love. -- Charlie Brown I'm off to find myself, if I return before I come back, please tell myself to wait...

I'd say the opposite is true. Midi is lame for visualizing a continuous data stream, say for example mapping frequency content or amplitude to a continuous visualization. While midi is easy to work with with, 7-bit cc values are pretty coarse. The trick to making the waveform visualiztion interesting is to allow the user to break up the composite waveform into user defined frequency bins so you can ride the amplitude of specific frequency areas. Iain

No, you're assuming this is a two-track only input. Why would the app be limited to two audio tracks only at once? What I would want to play with is something that allows: a) multi-track in, so that the music could be fed in with different instruments per track for say visuals coming off a live multi-track setup. b) filtering of tracks to seperate an individual track into more tracks for analysis. ie if you had only a two track input you could use user-controlled band pass filters to seperate the track into frequency bins, allowing you to zero in on say the underlying bass pulse, or underlying high end pulse. These could of course work side by side with midi too, but I would think the data available from audio analysis would be much richer and at a finer resolution. One could certainly do the above with either csound or PD ( among others I'm sure! ). The problem with the midi CC's is low resolution in both bit depth and time ( midi chokes at a pretty low message throughput ) and that of course you have to write these cc movements yourself to begin with. If that was the plan, I think it would be far preferable to just use Csound krate variables and make some sort of plugin/opcode to send the krate variables to whatever visualization engine one wanted. Fortunately this will actually be practical with all the new developments in Csound 5. Hooray to the csound developers! = ) Hope that makes some kind of sense, it's late here. ; ) Iain Iain

This is simply not true though! If you have an audio feed that is kick only, there is far more information available by analysing the audio than with a simple midi note on/velocity/duration. If the kick sound is spectrally analysed the light can be riding the amplitude and frequency content over the course of the note instead of just turning on when the drum starts. However, the above does require a *lot* more cpu use to break apart composite audio channels or a lot more hardware and cpu use to work on multi-track input. As I said earlier though, there is no reason not to enable both. Or even enable midi messages based on audio analysis. Iain

On Wed, 09 Jun 2004 00:02:22 -0400, Dave Robillard wrote I think it depends entirely what you want to do, sometimes midi is sufficient - but sometimes you want visuals that respond to the quality of the sounds too. There is something really cool about making visuals with your voice for instance :) Yeah - I want to see more gem work - and hear more pd generated music come to think of it. dave

On Wed, 2004-06-09 at 05:23, Dave Griffiths wrote: I considered using Pd for the majority of all my computer music schtuff, but I couldn't find a way to make descent polyphonic synths, which is a complete show stopper (at least for me) I've got my sights set on galan, it's like the best of Pd and AMS all rolled into one. It needs a little work on the polyphony/MIDI fronts though. Hopefully one day I'll get un-lazy and do something about it. :) -Dave Robillard

On Tue, 2004-06-08 at 21:29, Dave Phillips wrote: HASAS already has these kinds of output: http://www.sonarnerd.net/projects/hasas/HASAS-Spectrogram.png http://www.sonarnerd.net/projects/hasas/websgram.jpg So basically it could be OK with 3D display? -- Jussi Laako <jussi.laako(a)pp.inet.fi>

On Tue, Jun 08, 2004 at 02:29:08 -0400, Dave Phillips wrote: If anyone does want to implement this it would make a nice addition to meterbridge - the CVS version can (optionally) use OpenGL for rendering anyway, and it would be a logical place to put it. A side note; the reson for using OpenGL is that it massivly reduces the CPU load (if you have hardware acceleration working), and allows windows full of meters to be scaled, which is pretty useful. - Steve

On Tue, 08 Jun 2004 09:32:18 -0400, Dave Phillips wrote you might be able to knock something up like this as a script in fluxus: http://www.pawfal.org/Software/fluxus/ plug plug! :) cheers, dave

Hi Dave: Trying to compile fluxus: [dlphilp@localhost fluxus-0.5rc1]$ make g++ -c -pipe -Wall -O3 -ffast-math -DNO_DEBUG -Wno-unused -fPIC -Isrc -Ilibfluxphysics/src -Ilibfluxus/src -I/usr/local/include -I/usr/X11R6/include -o libfluxphysics/src/Physics.o libfluxphysics/src/Physics.cpp In file included from libfluxphysics/src/Physics.cpp:18: libfluxphysics/src/Physics.h:18:29: fluxus/Renderer.h: No such file or directory [snip] Indeed, there's no such directory. The file is there in ~/fluxus-0.5rc1/libfluxus/src but your includes for Physics.h (and maybe other files?) expect different. Grrr... ;) Best, dp Dave Griffiths wrote:

hi dave, I read: . . . that is precisely the problem fluxus needs pa 18, you could install a v18 somewhere else on your fs and put it in the makefile or I have made some patches against the previous version of fluxus to compile against pa 19, I could send them your way if you feel like rolling up your sleeves. regards, x BTW: does pa 19 do jack these days ? is OSC back in csound5 ? -- chris(a)lo-res.org Postmodernism is german romanticism with better http://pilot.fm/ special effects. (Jeff Keuss / via ctheory.com)

On Tue, 08 Jun 2004 16:59:25 -0400, Dave Phillips wrote I've had quite big problems with PA19 - hence fluxus is still on 18. Mainly that OSS support is broken and the jack support is old, maybe it's better now. I should really contribute to PortAudio instead of whinging, but too little time :( You mentioned compile problems with the physics stuff? Are you using the latest build? (0.5rc1) What were the problems? To do fine grained audio work like this you would need to configure the number of harmonics the fft calculates from the audio stream (currently fixed to 16) Added to the todo... cheers, dave

On Tue, Jun 08, 2004 at 04:59:25 -0400, Dave Phillips wrote: Csound5 doesnt have OSC yet. I thought about volunteering to fix it, but I've seen the insides of Csound before :-/ - Steve

Something like the above with a Snd style scripting language would be hella cool. Iain