sp branch now compiles + links under linux

[interim_descriptor]

Hey sp.

I've got to hurry off to work, but I checked in some very minor changes to your branch (A #define, a couple necessary #includes, and a tiny Makefile fix). It now compiles + links under linux!

As a rule, I'll only make changes to your branches that you've requested ("Could you compile this under linux?"), or that we've discussed.

I should have the bandwidth for a full set of replies tonight.

-Chris

PS. Your branch is looking good! Let me know when those last changes we discussed are ready, and we can sort out the merge-to-trunk dance.

[synthesizer patel]

Sweet deal on getting the linux stuff working. I've been super busy at
work so I'm sorry I couldn't ensure the changes across the board.

I need to look around and see what the clean/standard convention for
object/bin -> arch/os directory structure is. I'm thinking if we want
to go whole hog just to do the 'gcc -dumpmachine' style like

i686-apple-darwin9

Does that jive with you?

Could then do

dvj/
bin/i686-apple-darwin9/dvj <-- exe
bin/i686-apple-darwin9/tools/logDrawer <-- exe
build/i686-apple-darwin9/*.o
src/*.c

etc

I'd like to switch .h to .hpp and I'll get ctags working again too

-n


On Jun 24, 7:22 am, interim_descriptor <interim.descrip...@gmail.com>
wrote:

[interim_descriptor]

Ditto with the super-busy at work & sorry thing...

gcc -dumpmachine jives with me. I'd like dvj and logDrawer and all the other executables to ultimately live at the topmost dvj folder, unless you have a reason they shouldn't. If necessary, we can do this via symlink into the dumpmachine subfolders, but I'd like them to be present in some form at the end of make.

More later!

-Chris

[synthesizer patel]

I finally have some time to sit down and get this finished. I've found
a good prototype to model the build/object directory stuff on and will
be implementing it sometime tonight.

I've gone through with a couple code analysis tools and taken a high
level look at the structure, things make more sense now. I think I'll
keep my hands out of the guts as I fear I'll hinder your progress on
porting if I'm mucking about in general areas, it's been a bit quiet
on comms so given the lower amounts of communications I think it makes
more sense to reduce the intertwining of efforts.

I've got my vinyl decoding stuff compiling up with fftw and need to
look at the jack interfaces to understand how that'll all fit
together.

-n

On Jun 24, 2:06 pm, interim_descriptor <interim.descrip...@gmail.com>
wrote:

> Ditto with the super-busy at work & sorry thing...
>
> gcc -dumpmachine jives with me. I'd like dvj and logDrawer and all the other
> executables to ultimately live at the topmost dvj folder, unless you have a
> reason they shouldn't. If necessary, we can do this via symlink into the
> dumpmachine subfolders, but I'd like them to be present in some form at the
> end of make.
>
> More later!
>
> -Chris
>
> On Wed, Jun 24, 2009 at 9:57 AM, synthesizer patel

> <googlec...@nym.hush.com>wrote:

[interim_descriptor]

Yeah, sorry again about not being able to reply on this email list for a little while, last week.

As soon as we hit July, I should be in a much less busy state, and my replies shouldn't be delayed as they have been.

...wait, your code analysis tools report that my code made sense?? Clearly, there's something terribly wrong with them.

...by which I mean, I'm glad the organization isn't so bad such that it can't be parsed.

If there's any specific areas you'd like to muck around in, and you're uncertain, by all means, post to the list.

It's always exciting to hear you talk about the vinyl code! Regarding JACK, I've got it accepting audio input (works on linux, untested on OSX, but it should work also). That all goes down in the function lgl_AudioOutCallbackJack() (Which is misnamed, since it does more than AudioOut, these days). lgl_fft() provides a wrapper for fftw, but I bet you've already interfaced with fftw in your own way. Don't feel obligated to use lgl_fft().

-Chris