OSX Port
56 views
Skip to first unread message
interim_descriptor
Jun 16, 2009, 11:08:39 PM6/16/09
to dvj-dev
Note: This thread is a replay of a conversation between myself and
synthesizer patel, regarding the OSX port of dvj. It's posted here as
there's much useful information for developers new to the project.
synthesizer patel, regarding the OSX port of dvj. It's posted here as
there's much useful information for developers new to the project.
interim_descriptor
Jun 16, 2009, 11:18:46 PM6/16/09
to dvj-dev
[From synthesizer patel]
Hey there,
I'm synthesizer patel, short hair, 6'5", big guy -- we met Saturday @ Makers Faire, I tried to check out dvj to get it compiled up and ran into this:
Fetching external item into 'dvj/tools/frameRateTest/src/
Hey there,
I'm synthesizer patel, short hair, 6'5", big guy -- we met Saturday @ Makers Faire, I tried to check out dvj to get it compiled up and ran into this:
Fetching external item into 'dvj/tools/frameRateTest/src/
LGL.module'
Authentication realm: <https://dvj.googlecode.com:443> Google Code Subversion Repository
Password for 'root':
If I ignore externals, it checks out ok, but beyond that file am I missing out on anything important? Also, if I do get it compiled up, would you have any interest in me floating an OSX installer upstream to you?
-n
Authentication realm: <https://dvj.googlecode.com:443> Google Code Subversion Repository
Password for 'root':
If I ignore externals, it checks out ok, but beyond that file am I missing out on anything important? Also, if I do get it compiled up, would you have any interest in me floating an OSX installer upstream to you?
-n
interim_descriptor
Jun 16, 2009, 11:20:05 PM6/16/09
to dvj-dev
[From interim_descriptor]
Hey Nate!
Yeah, I remember you! That's seriously awesome you're trying out dvj.
I've just fixed the svn:externals issue you reported. An svn update on your end should provide you with all the source code. Thanks for that report!
Your progress, either on OSX or elsewhere, is of extreme interest to me. Should you encounter difficulties, you can count on full and immediate assistance.
I would ecstatically accept an OSX installer! Items that might need to be resolved before that's distributable to the general public:
Please don't hesitate to keep me informed of even the smallest details.
Good luck!
And thank you very much for offering to help out!
-Chris
PS. My most recent recorded video-set with dvj: http://vimeo.com/3184495
PPS. You're so busted for being logged in as root!
Hey Nate!
Yeah, I remember you! That's seriously awesome you're trying out dvj.
I've just fixed the svn:externals issue you reported. An svn update on your end should provide you with all the source code. Thanks for that report!
Your progress, either on OSX or elsewhere, is of extreme interest to me. Should you encounter difficulties, you can count on full and immediate assistance.
I would ecstatically accept an OSX installer! Items that might need to be resolved before that's distributable to the general public:
- LGL_ThreadSetPriority() may need to be initially stubbed out for compilation to succeed. It will also need to later be implemented.
- MIDI input likely isn't available from /dev/sequencer on OSX. This should fail gracefully, but MIDI input won't work without OSX-specific code.
- Wiimote input will need to be disabled. I don't really care to port this to OSX, as it's more of a tech demo than a useful feature.
- Testing:
I need to be sure the OSX port is rock-solid before distributing. (And
an installer is a great way to help me test that!)
- Unknown unknowns. This list certainly isn't exhaustive.
Please don't hesitate to keep me informed of even the smallest details.
Good luck!
And thank you very much for offering to help out!
-Chris
PS. My most recent recorded video-set with dvj: http://vimeo.com/3184495
PPS. You're so busted for being logged in as root!
interim_descriptor
Jun 16, 2009, 11:21:30 PM6/16/09
to dvj-dev
[From synthesizer_patel]
Hey dude, thanks for the response, having put a couple projects out into the wild I know how rad it is to realize someone else gives a shit, and rightly so, because I do. I think dvj is nifty.
Hey dude, thanks for the response, having put a couple projects out into the wild I know how rad it is to realize someone else gives a shit, and rightly so, because I do. I think dvj is nifty.
So
far I've run into a couple snags getting it compiled, I'm at work right
now (doing an overhaul on some stuff here that's ended up taking me all
day), but roughly this is what my situation is:
I'm
on OSX 10.5.7 (latest), got the bulk of the required packages
installed, ran into a snag with the wiimote stuff as it requires
bluetooth lib which I think is linux only -- or are you using something
cross-compatible? Basically I got stuck @ compiling LGL.module and
started ifdef'ing out all the bluetooth/wiimote stuff.
Is there some simple define I can use to get the wiimote stuff quelled? O
As
far as your caveats for OSX integration, the MIDI assessment is
correct, it's got funky core-audio stuff that would need to be fixed.
As well, I'd be inclined to try and get it working directly with
core-audio for the dsp, just because Jack on OSX is really flakey (or
has been for me) -- those two items might be insurmountable by my
meager skill set but.. who knows.
I've got
some big ideas but who knows, as far as vinyl code I've been sitting on
some custom vinyl decoding stuff that works universally with all
digital vinyl for speed/direction, I think absolute vinyl position is
pointless -- why bother moving a needle when you can hit a key? I
prototyped my code in Reaktor and have rewritten it in C++, but I got
stuck at the OpenGL shit. Right now the project is just a VST with a
rainbow pyramid that rotates in relationship to the speed/direction of
the record.. Kinda hohum but it's the highest quality amateur vinyl
decoder, and actually better than some professional ones that're still
using zero-crossing..
On an average week how
much time do you spend on vdj? I'm not expecting 1:1 commitment from
you, I know full well how it is once you get a project done you kinda
just say 'well, that was cool' and move on sometimes. So if thats the
case don't feel any pressure from me -- that's the magic of GPL right?
You do something cool and it gets a life of it's own. Either way I'll
send you what I do.
and yeah... busted as
root.. heh. If it counts, I haven't f'd up a system accidentally in
more than 10 years, but maybe I just jinxed it.
-n
interim_descriptor
Jun 16, 2009, 11:23:29 PM6/16/09
to dvj-dev
[From interim_descriptor]
Give me a moment, and I'll #ifdef the wiimote stuff...
[5 minutes later...]
I've surrounded the wiimote stuff with #ifdef LGL_WIIMOTE_LINUX, which only gets #defined at the top of LGL.cpp if LGL_LINUX is defined.
svn updating on your end should result in no more wiimote/bluetooth errors. Let me know if I'm wrong.
(full replly forthcoming...)
-Chris
Give me a moment, and I'll #ifdef the wiimote stuff...
[5 minutes later...]
I've surrounded the wiimote stuff with #ifdef LGL_WIIMOTE_LINUX, which only gets #defined at the top of LGL.cpp if LGL_LINUX is defined.
svn updating on your end should result in no more wiimote/bluetooth errors. Let me know if I'm wrong.
(full replly forthcoming...)
-Chris
interim_descriptor
Jun 16, 2009, 11:24:14 PM6/16/09
to dvj-dev
[From synthesizer patel]
checking out over the pea-strainer connection at work...
checking out over the pea-strainer connection at work...
grep -R LGL_WIIMOTE_LINUX | wc -l == 0
Maybe your checkin didn't work?
Also,
how do you expect people to build? just make? or make LGL_OSX=1? This
makefile is a little different than what I'm used to, so I might be
doing things wrong.
-n
interim_descriptor
Jun 16, 2009, 11:25:33 PM6/16/09
to dvj-dev
[From interim_descriptor]
Hello!
First off, I should tell you what LGL is. LGL is a layer very much like SDL, which shields the application code in the main src folder from caring about which OS it's running on, as well as providing loads of convenience objects and functions (LGL_Sounds, and LGL_DrawLineToScreen(), for example). It's pretty much SDL on steroids. It's also somewhat messy in places.
That's quite interesting that JACK isn't so hot on OSX... I had no idea! LGL's audio code natually falls back on SDL's audio output, if JACK fails to initialize (such as when the user has a bunk ~/.jackrc). SDL's audio output, in turn, supports many audio drivers. I would be surprised if Core Audio weren't among them. As such, you might merely need to #ifdef out the call to LGL_JackInit() in LGL_Init(), if you want to use SDL for audio output. The only remaining concern, here, is getting the audio thread to run at realtime priority. Were LGL_ThreadSetPriority() implemented for OSX, then the SDL audio thread would have realtime priority.
Audio input is currently supplied by JACK. SDL doesn't provide audio input. I previously used the SDL library "SDL_audioin" for audio input, but upon discovering there was no OSX port, I abandoned it in favor of JACK. We could theoretically use JACK merely for input. Input isn't currently critical for anything, but it does allow dvj to respond to a line-in signal, so the user can VJ with frequency-sensitive visuals for an audio artist (which I'll be doing this Friday for UK's Broken Note, and then Saturday for Exillon).
Also, I would kill for vinyl control code. I agree that the needle-drop feature isn't terribly useful. I believe you that your code is top-notch. I heard reports that Mixxx's vinyl code is somewhat lacking.
I spend a lot time working on dvj. Really, it's only limited by the time I spend using dvj, which has happily increased significantly, as each party I play seems to result in two or more invites for other parties.
Looks like you just sent me an email, so I'll send this and then read yours.
-Chris
Hello!
First off, I should tell you what LGL is. LGL is a layer very much like SDL, which shields the application code in the main src folder from caring about which OS it's running on, as well as providing loads of convenience objects and functions (LGL_Sounds, and LGL_DrawLineToScreen(), for example). It's pretty much SDL on steroids. It's also somewhat messy in places.
That's quite interesting that JACK isn't so hot on OSX... I had no idea! LGL's audio code natually falls back on SDL's audio output, if JACK fails to initialize (such as when the user has a bunk ~/.jackrc). SDL's audio output, in turn, supports many audio drivers. I would be surprised if Core Audio weren't among them. As such, you might merely need to #ifdef out the call to LGL_JackInit() in LGL_Init(), if you want to use SDL for audio output. The only remaining concern, here, is getting the audio thread to run at realtime priority. Were LGL_ThreadSetPriority() implemented for OSX, then the SDL audio thread would have realtime priority.
Audio input is currently supplied by JACK. SDL doesn't provide audio input. I previously used the SDL library "SDL_audioin" for audio input, but upon discovering there was no OSX port, I abandoned it in favor of JACK. We could theoretically use JACK merely for input. Input isn't currently critical for anything, but it does allow dvj to respond to a line-in signal, so the user can VJ with frequency-sensitive visuals for an audio artist (which I'll be doing this Friday for UK's Broken Note, and then Saturday for Exillon).
Also, I would kill for vinyl control code. I agree that the needle-drop feature isn't terribly useful. I believe you that your code is top-notch. I heard reports that Mixxx's vinyl code is somewhat lacking.
I spend a lot time working on dvj. Really, it's only limited by the time I spend using dvj, which has happily increased significantly, as each party I play seems to result in two or more invites for other parties.
Looks like you just sent me an email, so I'll send this and then read yours.
-Chris
interim_descriptor
Jun 16, 2009, 11:26:18 PM6/16/09
to dvj-dev
[From interim_descriptor]
Sorry, I got that wrong.
The correct #define to grep is LGL_LINUX_WIIMOTE.
Currently, the only build path I expect to succeed is make under linux.
The Makefile is indeed a little large/complicated, but back when I was actually compiling for the OSX and win32 targets, a few years ago, all that was necessary was for the user to type "make" at a bash prompt, no matter what OS.
One thing that'll need to be fixed is the libraries that are linked to under OSX, primarily in the LGLLIBRARIES_OSX Makefile variable. It no longer needs to link to smpeg, for instance, and it'll likely need to link to JACK (unless JACK get #ifdef'd out).
I'm likely going to sleep fairly soon, but I'll respond to any emails you send tomorrow morning.
-Chris
Sorry, I got that wrong.
The correct #define to grep is LGL_LINUX_WIIMOTE.
Currently, the only build path I expect to succeed is make under linux.
The Makefile is indeed a little large/complicated, but back when I was actually compiling for the OSX and win32 targets, a few years ago, all that was necessary was for the user to type "make" at a bash prompt, no matter what OS.
One thing that'll need to be fixed is the libraries that are linked to under OSX, primarily in the LGLLIBRARIES_OSX Makefile variable. It no longer needs to link to smpeg, for instance, and it'll likely need to link to JACK (unless JACK get #ifdef'd out).
I'm likely going to sleep fairly soon, but I'll respond to any emails you send tomorrow morning.
-Chris
interim_descriptor
Jun 16, 2009, 11:26:59 PM6/16/09
to dvj-dev
[From synthesizer patel]
Well, to be honest I've never given Jack a fair shake.. I'll need to dig into it to understand, makes more sense than throwing away stuff that's already done.
Well, to be honest I've never given Jack a fair shake.. I'll need to dig into it to understand, makes more sense than throwing away stuff that's already done.
To give you an idea of my
creative interest, I'm still beating the midi/vinyl controlled sampler
horse. I suck at scratching, but the juice here is that if you think of
the vinyl as a tread-mill that you can drop samples on, why not drop
multiple samples simultaneously. That's the micro view. The macro view
is, this should be part of digital djing as a default utility. A couple
commercial apps have implemented the idea since I came out with this a
year or so ago, but still aren't doing it the 'right way' in my
opinion. It's a basic idea but, I can at least say I was the first. :p
interim_descriptor
Jun 16, 2009, 11:27:26 PM6/16/09
to dvj-dev
[From synthesizer patel]
aite, I'll take a looksee.
aite, I'll take a looksee.
re: sleep, I'll catch up with you later, thanks for the quick responses.
-n
interim_descriptor
Jun 16, 2009, 11:28:03 PM6/16/09
to dvj-dev
[From interim_descriptor]
Those videos were way cool!
You do too know how to scratch!! My scratching skills don't even approach that.
I'm most certainly open to incorporating your multi-sample scratching into dvj. That's clearly a powerful idea, and one I hadn't considered before. Assuming you have the engine-side code covered, the primary question is how we'd expose this capability to users in a way that makes sense with the rest of dvj, and it's minimal interface design. This is doubtlessly solvable.
On the video side, I actually do something interesting for scratching: Optionally, the user may cause a different video to load each time they place their hand on M-Audio Xponent's seek-wheels. This allows for effortless rapid video-switching while video-scratching. I could easily see this being reproduced with vinyl controllers.
By all means, don't be shy about suggesting micro and macro ideas. When I have an experimental idea that I'm not yet sure how to work into the user interface, I often add it to dvj in a way such that it's hidden from normal users, until I am able to add it to the UI in a satisfactory way.
Sleep now!
-Chris
Those videos were way cool!
You do too know how to scratch!! My scratching skills don't even approach that.
I'm most certainly open to incorporating your multi-sample scratching into dvj. That's clearly a powerful idea, and one I hadn't considered before. Assuming you have the engine-side code covered, the primary question is how we'd expose this capability to users in a way that makes sense with the rest of dvj, and it's minimal interface design. This is doubtlessly solvable.
On the video side, I actually do something interesting for scratching: Optionally, the user may cause a different video to load each time they place their hand on M-Audio Xponent's seek-wheels. This allows for effortless rapid video-switching while video-scratching. I could easily see this being reproduced with vinyl controllers.
By all means, don't be shy about suggesting micro and macro ideas. When I have an experimental idea that I'm not yet sure how to work into the user interface, I often add it to dvj in a way such that it's hidden from normal users, until I am able to add it to the UI in a satisfactory way.
Sleep now!
-Chris
interim_descriptor
Jun 16, 2009, 11:28:34 PM6/16/09
to dvj-dev
[From synthesizer patel]
Hey dude, got home and gave it a spin, LGL.h has a lot of wiimote references that still don't get handled, as well in the LGL makefile under the OSX specific stuff there's
DEFINES_OSX = -DLGL_LINUX -DLGL_OSX
I can understand why that's there but, I think it goes a bit deeper.
Another thing, there's no mlockall() on OSX -- not sure if it's better to one off these things or just send you a diff, but, I've been up all night at work and wanted to check it out before I went to bed. I'll catch up with you later, I've got a lot of stuff to write, just not the energy right now.
-n
Hey dude, got home and gave it a spin, LGL.h has a lot of wiimote references that still don't get handled, as well in the LGL makefile under the OSX specific stuff there's
DEFINES_OSX = -DLGL_LINUX -DLGL_OSX
I can understand why that's there but, I think it goes a bit deeper.
Another thing, there's no mlockall() on OSX -- not sure if it's better to one off these things or just send you a diff, but, I've been up all night at work and wanted to check it out before I went to bed. I'll catch up with you later, I've got a lot of stuff to write, just not the energy right now.
-n
interim_descriptor
Jun 16, 2009, 11:29:36 PM6/16/09
to dvj-dev
[From interim_descriptor]
Thanks for that report!
I've surrounded the wiimote references in LGL.h with the appropriate #ifdefs, and also only #define LGL_LINUX_WIIMOTE if LGL_OSX isn't defined. The same applies to mlockall().
These changes are in svn.
That DEFINES_OSX variable is definitely a little hacky. OSX and Linux have so much in common, it usually makes sense to have the linux code active for the OSX port, but I really should have something like #ifdef LGL_UNIX, or LGL_POSIX, so the LGL_LINUX and LGL_OSX defines actually refer their OS. It wouldn't be difficult to make this change.
On Wednesday, I'll get my old Mac Mini out of storage, and fire it up, so I can be of more help to you.
-Chris
Thanks for that report!
I've surrounded the wiimote references in LGL.h with the appropriate #ifdefs, and also only #define LGL_LINUX_WIIMOTE if LGL_OSX isn't defined. The same applies to mlockall().
These changes are in svn.
That DEFINES_OSX variable is definitely a little hacky. OSX and Linux have so much in common, it usually makes sense to have the linux code active for the OSX port, but I really should have something like #ifdef LGL_UNIX, or LGL_POSIX, so the LGL_LINUX and LGL_OSX defines actually refer their OS. It wouldn't be difficult to make this change.
On Wednesday, I'll get my old Mac Mini out of storage, and fire it up, so I can be of more help to you.
-Chris
interim_descriptor
Jun 16, 2009, 11:30:05 PM6/16/09
to dvj-dev
[From interim_descriptor]
Hey.
Meant to mention this earlier: If you're in the East Bay, and bored, I'll be playing a dvj set tonight at Circuitry in the Ivy Room. Music starts at 9pm, though I'm not sure when I go on...
It's probably too late for you to make plans for this, but I thought I'd let you know anyways.
-Chris
Hey.
Meant to mention this earlier: If you're in the East Bay, and bored, I'll be playing a dvj set tonight at Circuitry in the Ivy Room. Music starts at 9pm, though I'm not sure when I go on...
It's probably too late for you to make plans for this, but I thought I'd let you know anyways.
-Chris
interim_descriptor
Jun 16, 2009, 11:30:42 PM6/16/09
to dvj-dev
[From synthesizer patel]
Hey Chris,
I live in Santa Cruz but work in Fremont, so normally this type of thing would be do-able, yesterday tho I had been up all night working so by the time I got home at noon I just went to bed! Otherwise keep me in the loop, I'd dig seeing you dvj in a better setting with some projectors.
Had an interesting idea driving home, basically either via MIDI or OSC, record all the 'events', kind of like how Traktor does with 'Native Mixes', basically so you could have the raw inputs you could then replay via MIDI or OSC to reproduce the set given the same files available. The sexy part of this would be in the ability to play a set, fix any mistakes and then replay offline to produce a 'studio produced set'.
As far as input devices, have you seen how Ableton does it? They've got this neat Python abstraction layer that you then just write a Python interface for to hook into their midi system.. Might be a good way to empower people to integrate arbitrary midi devices.
I'm unfortunately at work and would much rather be geeking out on this but I've gotta go run down some tasks for my boss, altho I just updated my dvj svn tree and will see if I have better luck after your changes.
-n
Hey Chris,
I live in Santa Cruz but work in Fremont, so normally this type of thing would be do-able, yesterday tho I had been up all night working so by the time I got home at noon I just went to bed! Otherwise keep me in the loop, I'd dig seeing you dvj in a better setting with some projectors.
Had an interesting idea driving home, basically either via MIDI or OSC, record all the 'events', kind of like how Traktor does with 'Native Mixes', basically so you could have the raw inputs you could then replay via MIDI or OSC to reproduce the set given the same files available. The sexy part of this would be in the ability to play a set, fix any mistakes and then replay offline to produce a 'studio produced set'.
As far as input devices, have you seen how Ableton does it? They've got this neat Python abstraction layer that you then just write a Python interface for to hook into their midi system.. Might be a good way to empower people to integrate arbitrary midi devices.
I'm unfortunately at work and would much rather be geeking out on this but I've gotta go run down some tasks for my boss, altho I just updated my dvj svn tree and will see if I have better luck after your changes.
-n
interim_descriptor
Jun 16, 2009, 11:31:39 PM6/16/09
to dvj-dev
[From synthesizer patel]
Another thing I ran across:
In the Makefile you use 'sdl-config --cflags' to get the SDL CFLAGS stuff, in OSX at least it yields the full path including '/SDL', but you include "#include SDL/SDL_*.h' to it doesn't find them.
-n
Another thing I ran across:
In the Makefile you use 'sdl-config --cflags' to get the SDL CFLAGS stuff, in OSX at least it yields the full path including '/SDL', but you include "#include SDL/SDL_*.h' to it doesn't find them.
-n
interim_descriptor
Jun 16, 2009, 11:32:16 PM6/16/09
to dvj-dev
[From synthesizer patel]
Couple more things
sys/soundcard.h I think is linux only
SNDCTL_MIDI_INFO I think is ossound
SEQ_MIDIPUTC I think is sys/soundcard.h
But, gettin' further!
-n
make LGL.module
g++-4.0 PrecompiledHeaders.gch
In file included from LGL.h:62,
from PrecompiledHeaders.pch:1:
/usr/local/include/SDL/SDL_
Couple more things
sys/soundcard.h I think is linux only
SNDCTL_MIDI_INFO I think is ossound
SEQ_MIDIPUTC I think is sys/soundcard.h
But, gettin' further!
-n
make LGL.module
g++-4.0 PrecompiledHeaders.gch
In file included from LGL.h:62,
from PrecompiledHeaders.pch:1:
/usr/local/include/SDL/SDL_
opengl.h:112:1: warning: "GL_GLEXT_VERSION" redefined
In file included from /System/Library/Frameworks/OpenGL.framework/Headers/gl.h:65,
from LGL.h:48,
from PrecompiledHeaders.pch:1:
/System/Library/Frameworks/OpenGL.framework/Headers/glext.h:181:1: warning: this is the location of the previous definition
/opt/local/include/libavcodec/avcodec.h:2349: warning: ‘ImgReSampleContext’ is deprecated (declared at /opt/local/include/libavcodec/avcodec.h:2343)
/opt/local/include/libavcodec/avcodec.h:2359: warning: ‘ImgReSampleContext’ is deprecated (declared at /opt/local/include/libavcodec/avcodec.h:2343)
LGL.h:1908: warning: ‘class LGL_MidiDevice’ has virtual functions but non-virtual destructor
LGL.h:1950: warning: ‘class LGL_MidiDeviceXponent’ has virtual functions but non-virtual destructor
g++-4.0 LGL.cpp
LGL.cpp: In function ‘bool LGL_Init(int, int, int, const char*)’:
LGL.cpp:1547: error: ‘SNDCTL_SEQ_NRMIDIS’ was not declared in this scope
LGL.cpp:1549: error: aggregate ‘midi_info midiInfo’ has incomplete type and cannot be defined
LGL.cpp:1553: error: ‘SNDCTL_MIDI_INFO’ was not declared in this scope
LGL.cpp: In member function ‘bool LGL_ShaderObj::SetVertAttributeFloatPrivate(char*, int, float, float, float, float)’:
LGL.cpp:4768: warning: format ‘%i’ expects type ‘int’, but argument 4 has type ‘void*’
LGL.cpp: In constructor ‘LGL_VideoEncoder::LGL_VideoEncoder(const char*, const char*)’:
LGL.cpp:8289: error: ‘struct AVStream’ has no member named ‘sample_aspect_ratio’
LGL.cpp:8289: error: ‘struct AVStream’ has no member named ‘sample_aspect_ratio’
LGL.cpp: In function ‘int lgl_MidiUpdate(void*)’:
LGL.cpp:17261: error: ‘SEQ_MIDIPUTC’ was not declared in this scope
LGL.cpp:17281: error: ‘SEQ_MIDIPUTC’ was not declared in this scope
LGL.cpp:17300: error: ‘SEQ_MIDIPUTC’ was not declared in this scope
LGL.cpp:17319: error: ‘SEQ_MIDIPUTC’ was not declared in this scope
LGL.cpp:17487: error: ‘SEQ_MIDIPUTC’ was not declared in this scope
LGL.cpp: In function ‘bool LGL_FileExists(const char*)’:
LGL.cpp:21396: error: ‘fopen64’ was not declared in this scope
LGL.cpp: In function ‘void LGL_ThreadSetPriority(float, const char*)’:
LGL.cpp:23884: error: ‘sched_setscheduler’ was not declared in this scope
LGL.cpp:23894: error: ‘sched_setscheduler’ was not declared in this scope
LGL.cpp:23902: error: ‘sched_setscheduler’ was not declared in this scope
LGL.cpp: In function ‘void LGL_ThreadSetCPUAffinity(int)’:
LGL.cpp:23912: error: ‘cpu_set_t’ was not declared in this scope
LGL.cpp:23912: error: expected `;' before ‘cpuSet’
LGL.cpp:23913: error: ‘cpuSet’ was not declared in this scope
LGL.cpp:23913: error: ‘CPU_ZERO’ was not declared in this scope
LGL.cpp:23914: error: ‘CPU_SET’ was not declared in this scope
LGL.cpp:23915: error: ‘sched_setaffinity’ was not declared in this scope
make[2]: *** [obj/osx/LGL.o] Error 1
make[1]: *** [LGL.module/obj/osx/module.osx.lib] Error 2
make: *** [default] Error 2
In file included from /System/Library/Frameworks/OpenGL.framework/Headers/gl.h:65,
from LGL.h:48,
from PrecompiledHeaders.pch:1:
/System/Library/Frameworks/OpenGL.framework/Headers/glext.h:181:1: warning: this is the location of the previous definition
/opt/local/include/libavcodec/avcodec.h:2349: warning: ‘ImgReSampleContext’ is deprecated (declared at /opt/local/include/libavcodec/avcodec.h:2343)
/opt/local/include/libavcodec/avcodec.h:2359: warning: ‘ImgReSampleContext’ is deprecated (declared at /opt/local/include/libavcodec/avcodec.h:2343)
LGL.h:1908: warning: ‘class LGL_MidiDevice’ has virtual functions but non-virtual destructor
LGL.h:1950: warning: ‘class LGL_MidiDeviceXponent’ has virtual functions but non-virtual destructor
g++-4.0 LGL.cpp
LGL.cpp: In function ‘bool LGL_Init(int, int, int, const char*)’:
LGL.cpp:1547: error: ‘SNDCTL_SEQ_NRMIDIS’ was not declared in this scope
LGL.cpp:1549: error: aggregate ‘midi_info midiInfo’ has incomplete type and cannot be defined
LGL.cpp:1553: error: ‘SNDCTL_MIDI_INFO’ was not declared in this scope
LGL.cpp: In member function ‘bool LGL_ShaderObj::SetVertAttributeFloatPrivate(char*, int, float, float, float, float)’:
LGL.cpp:4768: warning: format ‘%i’ expects type ‘int’, but argument 4 has type ‘void*’
LGL.cpp: In constructor ‘LGL_VideoEncoder::LGL_VideoEncoder(const char*, const char*)’:
LGL.cpp:8289: error: ‘struct AVStream’ has no member named ‘sample_aspect_ratio’
LGL.cpp:8289: error: ‘struct AVStream’ has no member named ‘sample_aspect_ratio’
LGL.cpp: In function ‘int lgl_MidiUpdate(void*)’:
LGL.cpp:17261: error: ‘SEQ_MIDIPUTC’ was not declared in this scope
LGL.cpp:17281: error: ‘SEQ_MIDIPUTC’ was not declared in this scope
LGL.cpp:17300: error: ‘SEQ_MIDIPUTC’ was not declared in this scope
LGL.cpp:17319: error: ‘SEQ_MIDIPUTC’ was not declared in this scope
LGL.cpp:17487: error: ‘SEQ_MIDIPUTC’ was not declared in this scope
LGL.cpp: In function ‘bool LGL_FileExists(const char*)’:
LGL.cpp:21396: error: ‘fopen64’ was not declared in this scope
LGL.cpp: In function ‘void LGL_ThreadSetPriority(float, const char*)’:
LGL.cpp:23884: error: ‘sched_setscheduler’ was not declared in this scope
LGL.cpp:23894: error: ‘sched_setscheduler’ was not declared in this scope
LGL.cpp:23902: error: ‘sched_setscheduler’ was not declared in this scope
LGL.cpp: In function ‘void LGL_ThreadSetCPUAffinity(int)’:
LGL.cpp:23912: error: ‘cpu_set_t’ was not declared in this scope
LGL.cpp:23912: error: expected `;' before ‘cpuSet’
LGL.cpp:23913: error: ‘cpuSet’ was not declared in this scope
LGL.cpp:23913: error: ‘CPU_ZERO’ was not declared in this scope
LGL.cpp:23914: error: ‘CPU_SET’ was not declared in this scope
LGL.cpp:23915: error: ‘sched_setaffinity’ was not declared in this scope
make[2]: *** [obj/osx/LGL.o] Error 1
make[1]: *** [LGL.module/obj/osx/module.osx.lib] Error 2
make: *** [default] Error 2
interim_descriptor
Jun 16, 2009, 11:32:53 PM6/16/09
to dvj-dev
[From interim_descriptor]
Great reports you're sending!
I've committed your suggested changes, and fixes to compile errors you reported.
For the AVStream sample_aspect_ratio errors, it seems I have a newer version of libffmpeg / libavformat than you do. sample_aspect_ratio is defined in the head revision of ffmpeg's svn repository. It would be good to know how you obtained your libffmpeg, so I can avoid that method, and also make a note of this potential pitfall on the Google code wiki.
All other LGL.cpp compile errors should be fixed in your next svn update.
Looking forward to your next results!
-Chris
Great reports you're sending!
I've committed your suggested changes, and fixes to compile errors you reported.
For the AVStream sample_aspect_ratio errors, it seems I have a newer version of libffmpeg / libavformat than you do. sample_aspect_ratio is defined in the head revision of ffmpeg's svn repository. It would be good to know how you obtained your libffmpeg, so I can avoid that method, and also make a note of this potential pitfall on the Google code wiki.
All other LGL.cpp compile errors should be fixed in your next svn update.
Looking forward to your next results!
-Chris
interim_descriptor
Jun 16, 2009, 11:33:51 PM6/16/09
to dvj-dev
[From interim_descriptor]
Your idea about recording MIDI / OSC input is very much along the lines of a plan I've been working towards! I like the way you think :-)
My take on your idea was to abstract all forms of user control input into the Input.h object. Derived InputObj objects, such as the InputXponentObj, all feed into a single InputObj, which is queried by the application each frame. By saving this InputObj's state each frame, we could later play it back!
The only minor issue is framerate hiccups: Some of the input state exists in the form of "Scroll down the file list at a rate of X files per second". This isn't optimal design, as it will produce different results each time it's played back, with different sets of framerate hiccups. It shouldn't be that difficult to make the InputObj framerate-independent. I do want to allow for recording / playing back input, exactly for the reasons you state. My plan, before you came into the picture, was to do this after all 3 OS ports were deployed. Should this feature arrive before then, there's no reason not to include it, provided we're able to work it into the UI in a clean way.
Speaking of UI, later, if you find yourself working on a feature that might affect the UI, let's first plan together how best to incorporate it into the UI. My philosophy is to keep the UI as minimal as possible, so up-front, it just looks like a pair of video-turntables, and a mixer, and nothing else. I think that music software with complicated interfaces scares away casual users. I intentionally avoid menus, dialog boxes, and even modes, where possible. I should also note that although I'm into adding every feature you've mentioned, I'm trying to keep more advanced ableton-like capabilities to a minimum. The idea is for dvj to do a small set of things, but to do them exceedingly well.
Random comment: I forgot whether I told you this or not, but dvj can currently record both audio and video of itself. It records audio directly to 320kbps mp3, and it records a zipped txt log of all LGL calls that eventually call OpenGL (Like LGL_DrawLineToScreen(), or LGL_Image::DrawToScreen()). As such, it's pretty easy to make a DVD / Bluray disc of your set (either the full interface, or just the visuals), with /dvj/tools/logDrawer. There's room to make this easier for the user. It's currently not documented, since it's not yet as easy as it should be.
More input comments: I'd love to write a generic InputMidiObj, that allows users to integrate arbitrary midi devices. It'd take a little bit of work on the LGL side of things, but not much. The same goes for an InputOscObj. Also, I'd like for InputKeyboardObj to read in a plaintext config file, so users can edit their controls, if desired. The current keyboard mappings are somewhat arbitrary, and not documented. One must look in InputKeyboard.cpp, and grep for "SDLK_", to see which button does what. Obviously this needs attention.
Lastly, this code is the product of 10 years of work. Much of it I'm proud of, but if you continue working on this project, you'll doubtlessly run into some cringe-inducing sections that were written from my highschool or early-college years. Don't hesitate to call these out as you find them, or let me know if you think a section could use some reworking. My ego is of minimal importance, relative to the quality I desire for dvj's code. I'm aware of plenty of these sections, and intend to clean them up after dvj has been deployed on all 3 OS's. But if a bad bit of code is getting into your way, I'm happy to address it earlier.
Sleep time for me now.
-Chris
Your idea about recording MIDI / OSC input is very much along the lines of a plan I've been working towards! I like the way you think :-)
My take on your idea was to abstract all forms of user control input into the Input.h object. Derived InputObj objects, such as the InputXponentObj, all feed into a single InputObj, which is queried by the application each frame. By saving this InputObj's state each frame, we could later play it back!
The only minor issue is framerate hiccups: Some of the input state exists in the form of "Scroll down the file list at a rate of X files per second". This isn't optimal design, as it will produce different results each time it's played back, with different sets of framerate hiccups. It shouldn't be that difficult to make the InputObj framerate-independent. I do want to allow for recording / playing back input, exactly for the reasons you state. My plan, before you came into the picture, was to do this after all 3 OS ports were deployed. Should this feature arrive before then, there's no reason not to include it, provided we're able to work it into the UI in a clean way.
Speaking of UI, later, if you find yourself working on a feature that might affect the UI, let's first plan together how best to incorporate it into the UI. My philosophy is to keep the UI as minimal as possible, so up-front, it just looks like a pair of video-turntables, and a mixer, and nothing else. I think that music software with complicated interfaces scares away casual users. I intentionally avoid menus, dialog boxes, and even modes, where possible. I should also note that although I'm into adding every feature you've mentioned, I'm trying to keep more advanced ableton-like capabilities to a minimum. The idea is for dvj to do a small set of things, but to do them exceedingly well.
Random comment: I forgot whether I told you this or not, but dvj can currently record both audio and video of itself. It records audio directly to 320kbps mp3, and it records a zipped txt log of all LGL calls that eventually call OpenGL (Like LGL_DrawLineToScreen(), or LGL_Image::DrawToScreen()). As such, it's pretty easy to make a DVD / Bluray disc of your set (either the full interface, or just the visuals), with /dvj/tools/logDrawer. There's room to make this easier for the user. It's currently not documented, since it's not yet as easy as it should be.
More input comments: I'd love to write a generic InputMidiObj, that allows users to integrate arbitrary midi devices. It'd take a little bit of work on the LGL side of things, but not much. The same goes for an InputOscObj. Also, I'd like for InputKeyboardObj to read in a plaintext config file, so users can edit their controls, if desired. The current keyboard mappings are somewhat arbitrary, and not documented. One must look in InputKeyboard.cpp, and grep for "SDLK_", to see which button does what. Obviously this needs attention.
Lastly, this code is the product of 10 years of work. Much of it I'm proud of, but if you continue working on this project, you'll doubtlessly run into some cringe-inducing sections that were written from my highschool or early-college years. Don't hesitate to call these out as you find them, or let me know if you think a section could use some reworking. My ego is of minimal importance, relative to the quality I desire for dvj's code. I'm aware of plenty of these sections, and intend to clean them up after dvj has been deployed on all 3 OS's. But if a bad bit of code is getting into your way, I'm happy to address it earlier.
Sleep time for me now.
-Chris
interim_descriptor
Jun 16, 2009, 11:35:09 PM6/16/09
to dvj-dev
[From synthesizer patel]
Hey dude,
Hey dude,
On Jun 3, 2009, at 1:45 AM, interim_descriptor wrote:
Your idea about recording MIDI / OSC input is very much along the lines of a plan I've been working towards! I like the way you think :-)
My take on your idea was to abstract all forms of user control input into the Input.h object. Derived InputObj objects, such as the InputXponentObj, all feed into a single InputObj, which is queried by the application each frame. By saving this InputObj's state each frame, we could later play it back!
The only minor issue is framerate hiccups: Some of the input state exists in the form of "Scroll down the file list at a rate of X files per second". This isn't optimal design, as it will produce different results each time it's played back, with different sets of framerate hiccups. It shouldn't be that difficult to make the InputObj framerate-independent. I do want to allow for recording / playing back input, exactly for the reasons you state. My plan, before you came into the picture, was to do this after all 3 OS ports were deployed. Should this feature arrive before then, there's no reason not to include it, provided we're able to work it into the UI in a clean way.
Speaking of UI, later, if you find yourself working on a feature that might affect the UI, let's first plan together how best to incorporate it into the UI. My philosophy is to keep the UI as minimal as possible, so up-front, it just looks like a pair of video-turntables, and a mixer, and nothing else. I think that music software with complicated interfaces scares away casual users. I intentionally avoid menus, dialog boxes, and even modes, where possible. I should also note that although I'm into adding every feature you've mentioned, I'm trying to keep more advanced ableton-like capabilities to a minimum. The idea is for dvj to do a small set of things, but to do them exceedingly well.
As far as widgets and whatnot.. I have a different opinion although I greatly respect the minimal UI design for a bunch of reasons, this is something that from an architectural standpoint you can't disagree with -- simple is better. But, here's my angle -- by compartmentalizing roles into discrete widgets (track waveform, video window, etc), you can make an abstract component that ultimately can be manipulated by 'power-users' or 'skinners'. Layout, colors, etc. All that stuff is pointless eye-candy but it's one of those things that software developers who nail are exceedingly more visible than software developers who ignore it.
Now, this is your project, you've been doing it for fun, it's a labor of love -- if you don't give a shit about those things, that's fine, right now I don't, but it's always one of those things in the back of my mind. So don't take any of this as a critique on your design or plan or any call to action.
Random comment: I forgot whether I told you this or not, but dvj can currently record both audio and video of itself. It records audio directly to 320kbps mp3, and it records a zipped txt log of all LGL calls that eventually call OpenGL (Like LGL_DrawLineToScreen(), or LGL_Image::DrawToScreen()). As such, it's pretty easy to make a DVD / Bluray disc of your set (either the full interface, or just the visuals), with /dvj/tools/logDrawer. There's room to make this easier for the user. It's currently not documented, since it's not yet as easy as it should be.
More input comments: I'd love to write a generic InputMidiObj, that allows users to integrate arbitrary midi devices. It'd take a little bit of work on the LGL side of things, but not much. The same goes for an InputOscObj. Also, I'd like for InputKeyboardObj to read in a plaintext config file, so users can edit their controls, if desired. The current keyboard mappings are somewhat arbitrary, and not documented. One must look in InputKeyboard.cpp, and grep for "SDLK_", to see which button does what. Obviously this needs attention.
Lastly, this code is the product of 10 years of work. Much of it I'm proud of, but if you continue working on this project, you'll doubtlessly run into some cringe-inducing sections that were written from my highschool or early-college years. Don't hesitate to call these out as you find them, or let me know if you think a section could use some reworking. My ego is of minimal importance, relative to the quality I desire for dvj's code. I'm aware of plenty of these sections, and intend to clean them up after dvj has been deployed on all 3 OS's. But if a bad bit of code is getting into your way, I'm happy to address it earlier.
My engineering mantra is:
1) make it work
2) make it work right
3) make it pretty
You've got 1 nailed, 2 could use a little work and it's already decently pretty. When I load up Deckadance and get the pixel-shotgun in the face of crap they slop on the gpu I can tell you straight up you're going the right direction -- they are not. Take that to heart.
Gotta go figure out how to cross-compile erlang on x86 for arm now. I'll hit you up later. I'm going to be looking at OSX MIDI stuff today to figure out how to abstract out the interface.
-nate
interim_descriptor
Jun 16, 2009, 11:35:41 PM6/16/09
to dvj-dev
[From synthesizer patel]
Finally got home before dark and my girl's out climbing -- I'm going to try to rock some code here.
Out of curiosity, what IDE do you use?
-n
Finally got home before dark and my girl's out climbing -- I'm going to try to rock some code here.
Out of curiosity, what IDE do you use?
-n
interim_descriptor
Jun 16, 2009, 11:36:18 PM6/16/09
to dvj-dev
[From interim_descriptor]
Awesome!
Just got home myself. I'll be available to reply to emails, though I'm meeting up with a beginner music/audio coder to help him with some stuff at 9pm.
IDE... You'll like this answer: I'm a vim guy :P
Reply to other email forthcoming...
-Chris
Awesome!
Just got home myself. I'll be available to reply to emails, though I'm meeting up with a beginner music/audio coder to help him with some stuff at 9pm.
IDE... You'll like this answer: I'm a vim guy :P
Reply to other email forthcoming...
-Chris
interim_descriptor
Jun 16, 2009, 11:36:52 PM6/16/09
to dvj-dev
[From synthesizer patel]
I guess the ctags file should have been the smoking gun on that one. :D
I've been a vi guy for a long time, but trying to train myself to use eclipse more for larger projects -- Apple's dev stack really treats you better when you use XCode but.. ugh. Xcode.
-n
I guess the ctags file should have been the smoking gun on that one. :D
I've been a vi guy for a long time, but trying to train myself to use eclipse more for larger projects -- Apple's dev stack really treats you better when you use XCode but.. ugh. Xcode.
-n
interim_descriptor
Jun 16, 2009, 11:38:13 PM6/16/09
to dvj-dev
[From synthesizer patel]
Dumb question, but have you looked at Juce as a cross-platform audio solution?
-n
Dumb question, but have you looked at Juce as a cross-platform audio solution?
-n
interim_descriptor
Jun 16, 2009, 11:38:58 PM6/16/09
to dvj-dev
[From interim_descriptor]
Hmm... I hadn't yet.
I've written my audio callback / initialization in a way such that it's quite easy to support multiple audio output APIs. I currently first try to initialize JACK, and then fallback on SDL (I think I told you this). If there were a reason to add Juce to the mix, I'd be game, provided it were low-latency and took advantage of an RT kernel.
Another guy at Maker Faire was using Juce for his music software, but the framerate was pretty miserable.
Also, good news! I just extracted my Mac Mini from a moving back, and set it up. As such, I'll now be able to test directly on OSX, and help you much more directly.
Considering getting my first Macbook, after the WWDC refresh, if there is one...
Time to start my first dvj OSX compile in years...
-Chris
Hmm... I hadn't yet.
I've written my audio callback / initialization in a way such that it's quite easy to support multiple audio output APIs. I currently first try to initialize JACK, and then fallback on SDL (I think I told you this). If there were a reason to add Juce to the mix, I'd be game, provided it were low-latency and took advantage of an RT kernel.
Another guy at Maker Faire was using Juce for his music software, but the framerate was pretty miserable.
Also, good news! I just extracted my Mac Mini from a moving back, and set it up. As such, I'll now be able to test directly on OSX, and help you much more directly.
Considering getting my first Macbook, after the WWDC refresh, if there is one...
Time to start my first dvj OSX compile in years...
-Chris
interim_descriptor
Jun 16, 2009, 11:39:37 PM6/16/09
to dvj-dev
[From synthesizer patel]
Sweet.
Yeah, I dunno.. Linux isn't that bad, OSX is just more friendly for music stuff for me.. I ended up switching over entirely.. If you don't use the mac mini you should at least throw XBMC on it.
The juce framerate thing.. yeah, I can see that.. You really can't beat the speed of raw opengl.
-n
Sweet.
Yeah, I dunno.. Linux isn't that bad, OSX is just more friendly for music stuff for me.. I ended up switching over entirely.. If you don't use the mac mini you should at least throw XBMC on it.
The juce framerate thing.. yeah, I can see that.. You really can't beat the speed of raw opengl.
-n
interim_descriptor
Jun 16, 2009, 11:40:42 PM6/16/09
to dvj-dev
[From synthesizer_patel]
Hey dude,
Just to touch base I've been playing around a bit with dvj in Linux (I broke down and reinstalled just to get some sort of victory). My hope is to still get some OSX stuff done but it's been pretty ugly trying to get some of the linuxisms to convert to OSXisms.
Either way, hope you're doing well -- would dig seeing you play out next time you do so keep in touch.
I've also revisited my vinyl code, I'm hoping to get a library up and available based on FFTW in the next couple weeks if you have any interest in integrating it.
-n
Hey dude,
Just to touch base I've been playing around a bit with dvj in Linux (I broke down and reinstalled just to get some sort of victory). My hope is to still get some OSX stuff done but it's been pretty ugly trying to get some of the linuxisms to convert to OSXisms.
Either way, hope you're doing well -- would dig seeing you play out next time you do so keep in touch.
I've also revisited my vinyl code, I'm hoping to get a library up and available based on FFTW in the next couple weeks if you have any interest in integrating it.
-n
interim_descriptor
Jun 16, 2009, 11:41:41 PM6/16/09
to dvj-dev
[From interim_descriptor]
Hey Nathan!
Sorry for the delay getting back to you: I was just on my way to a gig when I got your email, after which a friend (who's a vocalist for The Orb) and I went up to Santa Rosa to see The Orb play at 2am. ...and then we hung with with Alex Paterson & VJ Zebbler until 9am, at which point I drove back and promptly fell asleep. Absurdly fun night :)
Regarding OSX, I've crossed the Rubicon: I'm typing this from my new 13" Macbook Pro, bought today explicitly for porting dvj. There's been so much interest in the OSX version of dvj that it's now become my #1 priority, even above the Ubuntu release.
I'll be coding madly to take care of as much of the ugly linuxism => OSXism conversion as quickly as possible.
That's so great to hear you're working on putting your vinyl code into a library!! I have extreme interest in integrating it!
I'll keep you up to date on my OSX progress. How's working with dvj in linux going? Did you spot the linux HOWTO on the dvj wiki?
http://code.google.com/p/dvj/wiki/Installation
Please let me know if you encounter any difficulty with that guide, or in general!
-Chris
Hey Nathan!
Sorry for the delay getting back to you: I was just on my way to a gig when I got your email, after which a friend (who's a vocalist for The Orb) and I went up to Santa Rosa to see The Orb play at 2am. ...and then we hung with with Alex Paterson & VJ Zebbler until 9am, at which point I drove back and promptly fell asleep. Absurdly fun night :)
Regarding OSX, I've crossed the Rubicon: I'm typing this from my new 13" Macbook Pro, bought today explicitly for porting dvj. There's been so much interest in the OSX version of dvj that it's now become my #1 priority, even above the Ubuntu release.
I'll be coding madly to take care of as much of the ugly linuxism => OSXism conversion as quickly as possible.
That's so great to hear you're working on putting your vinyl code into a library!! I have extreme interest in integrating it!
I'll keep you up to date on my OSX progress. How's working with dvj in linux going? Did you spot the linux HOWTO on the dvj wiki?
http://code.google.com/p/dvj/wiki/Installation
Please let me know if you encounter any difficulty with that guide, or in general!
-Chris
interim_descriptor
Jun 16, 2009, 11:42:57 PM6/16/09
to dvj-dev
[From synthesizer patel]
Hey there,
Sweet to hear that you got to hang out with Alex Paterson, the Orb was one of the first 'electronic' bands that got me interested in the genre, must have been pretty cool!
Also glad to hear that you're focusing on the OSX part -- if you've got any project plan in mind I might be able to assist if you have anything specific.
My only advice (not that you asked) to you would be to avoid xcode like the plague. :p Worst IDE ever.
dvjing in linux is going ok, I jiggered a bit to get my VCI-100 v1 working, it's got a nasty firmware bug that they fixed but I never sent mine in to resolve.
Incidentally, I did a little bit of work with firewire video capture that you might dig now that you've got OSX handy -- http://www.remix.net/wiki/Clover
The jist of it is you can use your firewire to easily capture video from a cable box using a CLI tool. I had decent success using it and some of the mpegtx/ffmpeg stuff to get clips and convert into DJ friendly uncompressed quicktime, which should probably be avi for the future.
-n
Hey there,
Sweet to hear that you got to hang out with Alex Paterson, the Orb was one of the first 'electronic' bands that got me interested in the genre, must have been pretty cool!
Also glad to hear that you're focusing on the OSX part -- if you've got any project plan in mind I might be able to assist if you have anything specific.
My only advice (not that you asked) to you would be to avoid xcode like the plague. :p Worst IDE ever.
dvjing in linux is going ok, I jiggered a bit to get my VCI-100 v1 working, it's got a nasty firmware bug that they fixed but I never sent mine in to resolve.
Incidentally, I did a little bit of work with firewire video capture that you might dig now that you've got OSX handy -- http://www.remix.net/wiki/Clover
The jist of it is you can use your firewire to easily capture video from a cable box using a CLI tool. I had decent success using it and some of the mpegtx/ffmpeg stuff to get clips and convert into DJ friendly uncompressed quicktime, which should probably be avi for the future.
-n
interim_descriptor
Jun 16, 2009, 11:43:57 PM6/16/09
to dvj-dev
[From synthesizer patel]
One other dumb thing to mention, since I'm sure you're well up on this stuff more than I am, but Joshua Pearson recently updated his webpage and has a fair amount of clips I'd never seen before (Although, I've only got their VHS tape from ages ago)
When I got to thinking about VDJing a while ago I did the clover project to record clips from TV and automatically convert them into 'blocks' you could play around with. Here's a test example I did with Ableton. http://www.remix.net/static/test.mov
But.. anyway. It all comes back to EBN, when I look at these videos now I'm _still_ impressed by how amazing they are, then doing the math on when they were done.. yikes. They were so ahead of their time..
http://www.joshuapearson.com
One other dumb thing to mention, since I'm sure you're well up on this stuff more than I am, but Joshua Pearson recently updated his webpage and has a fair amount of clips I'd never seen before (Although, I've only got their VHS tape from ages ago)
When I got to thinking about VDJing a while ago I did the clover project to record clips from TV and automatically convert them into 'blocks' you could play around with. Here's a test example I did with Ableton. http://www.remix.net/static/test.mov
But.. anyway. It all comes back to EBN, when I look at these videos now I'm _still_ impressed by how amazing they are, then doing the math on when they were done.. yikes. They were so ahead of their time..
http://www.joshuapearson.com
interim_descriptor
Jun 16, 2009, 11:37:44 PM6/16/09
to dvj-dev
[From interim_descriptor]
Inline replies follow!
That's a very interesting thought... I like how it'd just hook up to dvj as an OSC input... Yeah, that could very well be the way to do it.
Don't ever hesitate to voice things you'd like to see in dvj.
Regarding skinning and custom layouts, that's truthfully not an immediate priority for me, but it's the type of thing I'd be happy to help guide you with implementing, if you decide that's what you'd like to work on. It's a good idea, after all!
My only plan for customization of this type, currently, is to some day allow the user to specify the "cool" and "hot" colors, which are currently deep blue and bright violet, respectively. dvj only uses those two colors, black, and white, for all its interface.
Oh! And regarding what are immediate priorities for me, I keep the Google code issue list up to date:
http://code.google.com/p/dvj/issues/list
The list sorted by milestone, but it's somewhat fluid. I don't hesitate to implement in whatever order I feel like, and the same applies to you.
Feel free to add bugs and/or features into the issue list. Feel free to stick them in the 9.9.9 / undefined milestone. The features necessary for reaching the 1.* milestones are pretty much what they should be. This isn't to say other features can't be included also, but I don't see any other necessary features, to reach these milestones.
This is another thing I'd be happy to assist you with. Let me know if you decide it's something you'd like to work on, once we get everything compiling & running.
Ha, thanks!
Yeah, dvj doesn't crash. Period. I never would have open sourced it unless all crash bugs were resolved. And I never would use it, either.
Glad you enjoyed my mixing! Someone else in the audience did, too, and invited me to DJ an art gallery opening. Possibly for 5 hours. Yikes.
Here's where I post all my music, if you're happen to like dubstep, idm, or breakcore:
http://interimdescriptor.blogspot.com/
I'm certain you can! Already you've put a lot of good ideas in my head, and got the OSX port *much* closer to compiling.
Also, feel no obligation to stick with this project beyond the scope of your interest. We're doing this for fun, and what interests us changes over time.
...But so long as this is something you want to work on, I'll appreciatively give you every bit of support I can, because it's way rad to have your help.
-Chris
Inline replies follow!
On Wed, Jun 3, 2009 at 11:50 AM, synthesizer patel wrote:
That's an interesting point of view and one that I try to stick with as well -- in fact the 'session recorder' utility I had been thinking about on the drive in to work today and came to the conclusion that it'd probably be best as it's own timeline based application, such that editing/saving/etc would simply capitalize on the MIDI or OSC communication on either end of the app -- keep it simple.
That's a very interesting thought... I like how it'd just hook up to dvj as an OSC input... Yeah, that could very well be the way to do it.
As far as widgets and whatnot.. I have a different opinion although I greatly respect the minimal UI design for a bunch of reasons, this is something that from an architectural standpoint you can't disagree with -- simple is better. But, here's my angle -- by compartmentalizing roles into discrete widgets (track waveform, video window, etc), you can make an abstract component that ultimately can be manipulated by 'power-users' or 'skinners'. Layout, colors, etc. All that stuff is pointless eye-candy but it's one of those things that software developers who nail are exceedingly more visible than software developers who ignore it.
Now, this is your project, you've been doing it for fun, it's a labor of love -- if you don't give a shit about those things, that's fine, right now I don't, but it's always one of those things in the back of my mind. So don't take any of this as a critique on your design or plan or any call to action.
Don't ever hesitate to voice things you'd like to see in dvj.
Regarding skinning and custom layouts, that's truthfully not an immediate priority for me, but it's the type of thing I'd be happy to help guide you with implementing, if you decide that's what you'd like to work on. It's a good idea, after all!
My only plan for customization of this type, currently, is to some day allow the user to specify the "cool" and "hot" colors, which are currently deep blue and bright violet, respectively. dvj only uses those two colors, black, and white, for all its interface.
Oh! And regarding what are immediate priorities for me, I keep the Google code issue list up to date:
http://code.google.com/p/dvj/issues/list
The list sorted by milestone, but it's somewhat fluid. I don't hesitate to implement in whatever order I feel like, and the same applies to you.
Feel free to add bugs and/or features into the issue list. Feel free to stick them in the 9.9.9 / undefined milestone. The features necessary for reaching the 1.* milestones are pretty much what they should be. This isn't to say other features can't be included also, but I don't see any other necessary features, to reach these milestones.
Ahh, yeah, I realized last night that the Python abstraction might be extreme overkill -- a simple mapping system is sufficient. A really cheap way of accomplishing this would be to come up with a simple data structure that could live in a .h or .cpp file, and use it as a target map generator, and then do something like Bome's Midi doodad where you could assign MIDI events/notes/cc's to the list of available actions. That'd be a really simple app to write. Something I could probably whip together if we coordinated.
This is another thing I'd be happy to assist you with. Let me know if you decide it's something you'd like to work on, once we get everything compiling & running.
Ahh, no sweat dude. I know how it is, and like I said -- you should be proud of what you've got. I was impressed when I saw it running and not crashing, I was estatic watching you DJ outside and it STILL not crashing (heh!), but that your set sounded really good and fluid. Most of the time when people write audio tools, the audio output with them at the helm is bad. You got the code and the creativity working for you. So yah, your code is crufty, everyone's is --
Ha, thanks!
Yeah, dvj doesn't crash. Period. I never would have open sourced it unless all crash bugs were resolved. And I never would use it, either.
Glad you enjoyed my mixing! Someone else in the audience did, too, and invited me to DJ an art gallery opening. Possibly for 5 hours. Yikes.
Here's where I post all my music, if you're happen to like dubstep, idm, or breakcore:
http://interimdescriptor.blogspot.com/
my hope is that I can help make it better.
I'm certain you can! Already you've put a lot of good ideas in my head, and got the OSX port *much* closer to compiling.
Also, feel no obligation to stick with this project beyond the scope of your interest. We're doing this for fun, and what interests us changes over time.
...But so long as this is something you want to work on, I'll appreciatively give you every bit of support I can, because it's way rad to have your help.
-Chris
interim_descriptor
Jun 16, 2009, 11:54:17 PM6/16/09
to dvj-dev
[From interim_descriptor]
I'm just about to head out to work, but I wanted to let you know I got dvj running on OSX!
I've attached a log of how I installed each dependency library. This will eventually go on the google code wiki with improved formatting.
An svn update will also be necessary.
Much work remains: The audio skips (since LGL_ThreadSetPriority isn't implemented, and JACK likely isn't running at RT priority), and I haven't tested videos yet. Still, I'm quite happy to have made it this far. Thanks for your help!!
Let me know if you're able to replicate my success, with the attached log, or if you run into a problem I didn't.
-Chris
I'm just about to head out to work, but I wanted to let you know I got dvj running on OSX!
I've attached a log of how I installed each dependency library. This will eventually go on the google code wiki with improved formatting.
An svn update will also be necessary.
Much work remains: The audio skips (since LGL_ThreadSetPriority isn't implemented, and JACK likely isn't running at RT priority), and I haven't tested videos yet. Still, I'm quite happy to have made it this far. Thanks for your help!!
Let me know if you're able to replicate my success, with the attached log, or if you run into a problem I didn't.
-Chris
interim_descriptor
Jun 16, 2009, 11:54:42 PM6/16/09
to dvj-dev
[From synthesizer patel]
You're a better developer than me, that much I already knew, congrats! I'll give this a try at lunch to see if I can replicate.
You're a better developer than me, that much I already knew, congrats! I'll give this a try at lunch to see if I can replicate.
-n
interim_descriptor
Jun 16, 2009, 11:55:35 PM6/16/09
to dvj-dev
[From interim_descriptor]
Not at all!
I'm just exceedingly familiar with that particular codebase.
And like I said, there's still a *ton* left to do before it's in any state I'd call "usable". Hopefully by tackling the base compilation / link / execute issues, I'll have allowed you to address issues that are genuinely interesting, rather than stupid stuff I coded that made porting to OSX needlessly difficult.
My next plan is to populate the Google Code issue tracker with as many bugs as I can find, so we both have a list of things we can work on. Feel free to add to this list, as well!
Also, it might very well be that your efforts are best placed in getting your vinyl code into a usable library. That's the type of thing where you're clearly the only expert between the two of us.
Will write proper replies to your original messages after work.
-Chris
Not at all!
I'm just exceedingly familiar with that particular codebase.
And like I said, there's still a *ton* left to do before it's in any state I'd call "usable". Hopefully by tackling the base compilation / link / execute issues, I'll have allowed you to address issues that are genuinely interesting, rather than stupid stuff I coded that made porting to OSX needlessly difficult.
My next plan is to populate the Google Code issue tracker with as many bugs as I can find, so we both have a list of things we can work on. Feel free to add to this list, as well!
Also, it might very well be that your efforts are best placed in getting your vinyl code into a usable library. That's the type of thing where you're clearly the only expert between the two of us.
Will write proper replies to your original messages after work.
-Chris
interim_descriptor
Jun 16, 2009, 11:56:11 PM6/16/09
to dvj-dev
[From synthesizer patel]
One thing to note that was odd, this bit in LGL.h blocked me up for a bit and it may be a problem other osx users will see if they use macports, basically the /opt/local/include stuff is essentially guaranteed to be 'older' than anything in /usr/local/bin and in a few cases broke things.
One thing to note that was odd, this bit in LGL.h blocked me up for a bit and it may be a problem other osx users will see if they use macports, basically the /opt/local/include stuff is essentially guaranteed to be 'older' than anything in /usr/local/bin and in a few cases broke things.
the prerequisites list was awesome and a time-saver, to round it off to full automation: the recipe for libjpeg from source is:
wget jpegsrc.v6b.tar.gz
tar -zvxf jpegsrc.v6b.tar.gz
cd jpeg-6b/
ln -s `which glibtool` ./libtool
make install
I'd say slap some 'cd ..'s on the end of each one and wiki that shiz.
I've got it compiled, when I run I'm getting jack errors that aren't fatal, but I do get this:
bash-3.2# ./dvj.osx
sh: pgrep: command not found
LGL_ThreadSetPriority(): Not implemented in OSX!
LGL JACK Initialization
---
jackd 0.116.2
Copyright 2001-2005 Paul Davis and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
JACK compiled with POSIX SHM support.
loading driver ..
allocate_mach_serverport: can't check in mach port
This device hasn't required input channels inchannels = 2 in_nChannels = 0
Cannot open the coreaudio driver
cannot load driver module coreaudio
poll failed (Bad file descriptor)
LGL_JackInit(): Error! jack_client_open() failed! status = 0x11
LGL_SAMPLESIZE_SDL not respected. Got 2048. Wanted 1024.
LGL_ThreadSetPriority(): Not implemented in OSX!
LGL_ThreadSetPriority(): Not implemented in OSX!
LGL Initialization
---
OS Linux
SDL 1.2.13
JACK Init FAILED
Are your ~/.jackrc and ~/.asoundrc correct?
Did you remember to killall pulseaudio?
Are any other programs using your soundcard?
SDL_AudioOut 4 channels. 2048 samples. coreaudio.
SDL_AudioIn Absent
MIDI Devices Absent
SDL_net Present
OpenGL Renderer NVIDIA GeForce 8600M GT OpenGL Engine
OpenGL VBO Present
GLSL Vert Shader Present
GLSL Frag Shader Present
1 joystick(s) found:
LGL_Joystick[0]: OSCulator HID 1
---
LGL_Image::LGL_Image(): Error loading 'data/fft_wisdom.jpg' to an SDL_Surface: Unsupported image format
Assertion failed: (false), function FileLoad, file LGL.cpp, line 6631.
Abort trap
*************************
I'll
give this another try when I get home. Time to drive. ttyl. I suspect I
may have compiled something that required jpeg, I thought I recompiled
everything but there may be something cached somewhere stupid.. So
chalk this up to my fault I'm sure.
-n
interim_descriptor
Jun 16, 2009, 11:56:49 PM6/16/09
to dvj-dev
[From interim_descriptor]
Hi!
I'm in a rush, as I need to deliver CDs to a release party ... now ... but quickly:
Try recompiling SDL_image. Specifically, look at the output of ./configure, and see whether it finds a jpeg decoding library or not. I ran into the exact same problem you did with fftwisdom.jpg...
I might very well take my laptop to the CD release party and work on dvj there, so don't be surprised if I'm able to reply to more emails tonight...
Lastly, your feedback on the dependency/compile process is invaluable, as I can't test how that sort of thing works for other people, myself, so thank you very much!
-Chris
Hi!
I'm in a rush, as I need to deliver CDs to a release party ... now ... but quickly:
Try recompiling SDL_image. Specifically, look at the output of ./configure, and see whether it finds a jpeg decoding library or not. I ran into the exact same problem you did with fftwisdom.jpg...
I might very well take my laptop to the CD release party and work on dvj there, so don't be surprised if I'm able to reply to more emails tonight...
Lastly, your feedback on the dependency/compile process is invaluable, as I can't test how that sort of thing works for other people, myself, so thank you very much!
-Chris
interim_descriptor
Jun 16, 2009, 11:57:18 PM6/16/09
to dvj-dev
[From synthesizer patel]
Took me a while to get back around to this, I recompiled SDL_image and now I'm cooking with gas.
Took me a while to get back around to this, I recompiled SDL_image and now I'm cooking with gas.
ROCK TEH F*** OUT
good
work! I wish I could have been more instrumental in getting it this far
but I'll take a look at what I can do to improve where it's at. You're
going to really get folks excited once they 'get it'. Don't get me
wrong, Linux is great, but this will generate you a loyal following
from the Windows and OSX crowd if you play your cards right.
Gonna try my VCI-100 patches and see if I can make it work on OSX
-n
interim_descriptor
Jun 16, 2009, 11:57:57 PM6/16/09
to dvj-dev
[From interim_descriptor]
Sweet!! Way glad it's working for you! ...well, running... "Working" doesn't quite describe it, yet.
Important command line options: --480p --720p
This will run dvj in a windowed mode, which is often helpful for debugging, especially with gdb.
Also, don't underestimate your role in getting it running on OSX! Your interest, enthusiasm, patches and reports were all instrumental in getting this party started. Now that we have it running, we can get to the critical task of making it run flawlessly. And we'll get there. In fact, I noticed the occasional framerate hiccups I've experienced in the linux version are completely absent in the OSX version. I can now blame NVIDIA's closed source linux drivers with increased confidence and ire.
I'm very excited to hear you're trying to get the VCI-100 working with it! A few months ago, I re-engineered the input subsystem to make adding input devices much easier. This is an area where I expect you could hop right in, with minimal difficulty. The only part that's a little tricky is making an LGL_VCI100, and populating it with the correct input state. Look to the LGL_Xponent in LGL.cpp, for guidance. Once you've got that, all you have to do is make an InputVCI100Obj (See InputXponent.[h|cpp] for guidance), and finally add it as a child to the master InputObj (see Main.cpp). Obviously, this all depends on reading MIDI data the OSX way, which apparently isn't via /dev/sequencer. If you figure out how to do that, let me know?
Last weekend, VJ Zebbler (who's apparently DJ Magazine's #12 ranked VJ) expressed massive interest in the OSX version. As did VJ Luna (a vocalist for The Orb). And a bunch of other people. Much more so than the linux version. I described what it did to Zebbler, and he wanted just a couple *really* trivial features (1920x480 output, for instance). So yeah, so far, so good... If we can get it running like the linux version, and be clever about adding our features in a way that preserves the UI's minimal simplicity... Well, I think some people might use it :)
Also, I just remembered I set up an email list for dvj on the Google Code page, a while ago... Would you mind if we migrated our conversation over there? It might encourage developers to see active discussion there. Any objections if I replay our email conversation, there, to seed the list with relevent and useful content?
Link: http://groups.google.com/group/dvj-dev?pli=1
Let me know if/when you've joined that group.
Also, since you're actually running dvj now, please don't hesitate to email me any bugs you find, no matter how trivial. My aim for this project is nothing short of perfection. I'll populate the issue tracker with anything you email me.
OK, this email is way overlong, and I *still* haven't commented on those projects you mentioned earlier!! Next one, I promise... Those look way cool.
Good luck, and happy coding!
-Chris
PS. If you want to have a code-a-thon some weekend, I'm game for driving over to your neck of the woods. July is my first free weekend.
Sweet!! Way glad it's working for you! ...well, running... "Working" doesn't quite describe it, yet.
Important command line options: --480p --720p
This will run dvj in a windowed mode, which is often helpful for debugging, especially with gdb.
Also, don't underestimate your role in getting it running on OSX! Your interest, enthusiasm, patches and reports were all instrumental in getting this party started. Now that we have it running, we can get to the critical task of making it run flawlessly. And we'll get there. In fact, I noticed the occasional framerate hiccups I've experienced in the linux version are completely absent in the OSX version. I can now blame NVIDIA's closed source linux drivers with increased confidence and ire.
I'm very excited to hear you're trying to get the VCI-100 working with it! A few months ago, I re-engineered the input subsystem to make adding input devices much easier. This is an area where I expect you could hop right in, with minimal difficulty. The only part that's a little tricky is making an LGL_VCI100, and populating it with the correct input state. Look to the LGL_Xponent in LGL.cpp, for guidance. Once you've got that, all you have to do is make an InputVCI100Obj (See InputXponent.[h|cpp] for guidance), and finally add it as a child to the master InputObj (see Main.cpp). Obviously, this all depends on reading MIDI data the OSX way, which apparently isn't via /dev/sequencer. If you figure out how to do that, let me know?
Last weekend, VJ Zebbler (who's apparently DJ Magazine's #12 ranked VJ) expressed massive interest in the OSX version. As did VJ Luna (a vocalist for The Orb). And a bunch of other people. Much more so than the linux version. I described what it did to Zebbler, and he wanted just a couple *really* trivial features (1920x480 output, for instance). So yeah, so far, so good... If we can get it running like the linux version, and be clever about adding our features in a way that preserves the UI's minimal simplicity... Well, I think some people might use it :)
Also, I just remembered I set up an email list for dvj on the Google Code page, a while ago... Would you mind if we migrated our conversation over there? It might encourage developers to see active discussion there. Any objections if I replay our email conversation, there, to seed the list with relevent and useful content?
Link: http://groups.google.com/group/dvj-dev?pli=1
Let me know if/when you've joined that group.
Also, since you're actually running dvj now, please don't hesitate to email me any bugs you find, no matter how trivial. My aim for this project is nothing short of perfection. I'll populate the issue tracker with anything you email me.
OK, this email is way overlong, and I *still* haven't commented on those projects you mentioned earlier!! Next one, I promise... Those look way cool.
Good luck, and happy coding!
-Chris
PS. If you want to have a code-a-thon some weekend, I'm game for driving over to your neck of the woods. July is my first free weekend.
interim_descriptor
Jun 17, 2009, 12:00:15 AM6/17/09
to dvj-dev
[From synthesizer patel]
When I load dvj now after getting it 'configured' I hear a continuous low sinewave tone, when I try to load mp3s I get this:
Do you have a sample jack config from your macbook? I suck at jack.
mp3 @ 0x19f3c00]mdb:38, lastbuf:0 skipping granule 0
LGL_Sound::LoadToMemory(): Couldn't find audio stream for 'data/music/A-Trak - Gangsta Breaks - 05 - samples.mp3' in 1 streams
LockAudio() 5
JackMachClientChannel::
When I load dvj now after getting it 'configured' I hear a continuous low sinewave tone, when I try to load mp3s I get this:
Do you have a sample jack config from your macbook? I suck at jack.
mp3 @ 0x19f3c00]mdb:38, lastbuf:0 skipping granule 0
LGL_Sound::LoadToMemory(): Couldn't find audio stream for 'data/music/A-Trak - Gangsta Breaks - 05 - samples.mp3' in 1 streams
LockAudio() 5
JackMachClientChannel::
ClientClose err = (ipc/mig) server died
-n
-n
interim_descriptor
Jun 17, 2009, 12:16:02 AM6/17/09
to dvj-dev
Ah, so you get that faint low tone, too!
I'm not entirely sure what's causing it, but my first guess would be to zero out the audio buffer we receive from JACK, to write into, in LGL_AudioOutCallbackJack().
The .jackrc I'm using is available on the wiki:
http://code.google.com/p/dvj/wiki/JACK
You may want to add the -R flag, and run as root, whenever you need to avoid audio hiccups. When using -R, always pass in -t 5000, so JACK doesn't kick dvj, and cut off all audio (unless dvj is unresponsive for 5000ms, which has not once happened). If you do ever happen to be kicked off, you'll get a cute bluescreen of death in the projector quadrent, and you may hit [F7] to reconnect to the JACK server. In an actual performance, this would turn a catastrophy into something amusing.
Regarding the LGL_Sound::LoadToMemory() error, my suspicion is your version of ffmpeg... Does it have mp3 support compiled in? I'm using the official ffmpeg 0.5 release. I've run into an error where ffmpeg crashes dvj on loading Zebbler's awesome Verminator video from vimeo. Although I haven't verified this, I don't believe this happens on the Ubuntu version. What's certain: We need to figure out exactly what kind of wrangling is necessary to get ffmpeg to behave on OSX.
I'll let you know when I'm able to test my theory regarding the tone. Probably not tonight, so if you want to give it a go, be my guest!
-Chris
I'm not entirely sure what's causing it, but my first guess would be to zero out the audio buffer we receive from JACK, to write into, in LGL_AudioOutCallbackJack().
The .jackrc I'm using is available on the wiki:
http://code.google.com/p/dvj/wiki/JACK
You may want to add the -R flag, and run as root, whenever you need to avoid audio hiccups. When using -R, always pass in -t 5000, so JACK doesn't kick dvj, and cut off all audio (unless dvj is unresponsive for 5000ms, which has not once happened). If you do ever happen to be kicked off, you'll get a cute bluescreen of death in the projector quadrent, and you may hit [F7] to reconnect to the JACK server. In an actual performance, this would turn a catastrophy into something amusing.
Regarding the LGL_Sound::LoadToMemory() error, my suspicion is your version of ffmpeg... Does it have mp3 support compiled in? I'm using the official ffmpeg 0.5 release. I've run into an error where ffmpeg crashes dvj on loading Zebbler's awesome Verminator video from vimeo. Although I haven't verified this, I don't believe this happens on the Ubuntu version. What's certain: We need to figure out exactly what kind of wrangling is necessary to get ffmpeg to behave on OSX.
I'll let you know when I'm able to test my theory regarding the tone. Probably not tonight, so if you want to give it a go, be my guest!
-Chris
interim_descriptor
Jun 17, 2009, 12:34:47 AM6/17/09
to dvj-dev
Hey, so I finally had a chance to check out Clover and your test Ableton video. Quite cool!
I could imagine routing data directly from Clover into one of dvj's turntables. This would let you audio+video scratch a live signal, and also jump to segments, like you were doing in that video. If you decide that's something you want to implement, let me know, and I'll give you more information about how to get that going. I think it'd have a minimal impact on the UI. If you get that going, I'll clearly have to start subscribing to a cable service ;-)
-Chris
PS. I initially misread read your wiki page in a most amusing way: It read like you actually named your dog "CloverTheDogAndNotASoftwareProject". Ha.
I could imagine routing data directly from Clover into one of dvj's turntables. This would let you audio+video scratch a live signal, and also jump to segments, like you were doing in that video. If you decide that's something you want to implement, let me know, and I'll give you more information about how to get that going. I think it'd have a minimal impact on the UI. If you get that going, I'll clearly have to start subscribing to a cable service ;-)
-Chris
PS. I initially misread read your wiki page in a most amusing way: It read like you actually named your dog "CloverTheDogAndNotASoftwareProject". Ha.
Reply all
Reply to author
Forward
0 new messages