Compile Juce Example in dev-c++ 4.9.9.0 (12 east steps) v1.2

[valley]

Is this the one Rock wanted? (speaking of which... where is the man?)

fraid so.

[ModuLR]

side comment: any luck on pushing the Dev-C++ and the demofilterplugin? I've got a shitload of errors.. I've applied the help for compiling the VST SDK with Dev-C rules, but stuff is still a bit funky...

[Robert Randolph]

OHHH I thought you were after something else valley. Im well aware of the difference between scripting and markup... I thougth valley was talking about something completely different. python it is then



What's the error's your getting modulr? It compiles alright for me, but Ive totally ripped JUCE to shreds already to get things working...

[ModuLR]

I might have to make a screen shot, it too many to list... I think it really just boils down to me not knowing what I'm doing to a great extent. Everything in Dev-C++ seems to require a degree of manual labor like entering libs to link to and what not... I'm not really used to doing this, so I don't know what I'm missing at times. I'll keep at it, maybe something will click...

[valley]

OHHH I thought you were after something else valley. Im well aware of the difference between scripting and markup... I thougth valley was talking about something completely different. python it is then

Why, what did you have in mind? I'm speccing the program out in my head now, so if you have any good ideas throw them out now.



Here's the current plan:

in an effort to make this easier to do as a collab, and to make it more customizable for various tracktioneers needs, I'm working on making the design as modular as possible.

The basic program will be a UI, not unlike T in appearance (prolly a bit obvious that). The transport area can be pretty much ripped off straight out of T, and the options on the left likewise. The center control panel will have all of the processes available for the sample.

A few different popup menus will be available from various standard buttons, szuch as 'process' which would show all available processing tools, such as normalise, vst plugs, or JUCE modules, and scripts.

The track area will be modular in design. Tracks are modules that basically show some kind of linear data. The basic track types would simply be a single mono waveform track, and a timeline track. The user can select which tracks they wish to have active in a profile (more in a second). For a standard wave editor therefore two wave tracks and a timeline track would be shown. For surround sound support the user would simply need to add from the menu 3 more waveform tracks (much like adding tracks in tracktion).

This approach has a couple of cool advantages namely:

very flexible for editing:

native support for 5.1 editing, or
you could use four tracks to edit two different stereo samples simultaneously, etc....

very easy to extend programmatically:

because the tracks are modules video support, for example, could be added via a plugin. This leaves room for people to develop entirely custom track components that do not natively fit with the basic goal of a wave editor.

Anyway, 'profiles'. To make this whole concept useab le, I figure a profile or template system could be used whereby a track set up is saved as a preset that can be selected from a list. In this way when you open the editor you can flick between 5.1, stereo, multitrack, video or whatever, layouts from a menu.

So before I try and sell the idea to my wife that leaving a gaping whole in a ceiling for a few weeks is an acceptable approach to domestic life whilst I mess around writing free software, does this sound like a concept worth pursuing, or am I going to be entirely on my own with this?

[ModuLR]

whoah! hardcore!

[Robert Randolph]

I need to think about it....

It's grand idea.. but like so many grand ideas, you're pitching a programmer's paradise to a room of musicians. I think this whole idea needs to be re-worked from a musician's perspective... something a musician can easily make use of without fiddling with (or making their own) custom modules...

I love the idea, but we have to find that common ground

[valley]

What I imagine is that the default state would contain exactly as much, and no more than your average musician needs.

IE, by default you open the app and it looks just like a bog standard stereo wave editor. Choose the 5.1 profile, and that's your 5.1 mode.

The only config that would be needed is setting your vst directory.

For people that wanted to take the application further, they can. How far they take it depends on how technical they are, or how generous with its' time the wider community is[1].

Think of the gravy stuff as being a bit like racks. Fun if you like that kind of thing, but you can ignore it if you don't. The basic editor will be just that, a basic editor.

[1] It would be easy for even semi-experienced coders to write useful python scripts that provide functionality requested by users with less programming know-how or time.

[valley]

I guess to back up:

at its' base level, the application needs to support:

cut/edit/copy/paste/insert
level control with envelope.
normalise.
resverse.

that's pretty much everything a simple wave editor needs to know how to do, and support for VSTs pretty much opens the up the rest of everything you'd ever need.

by allowing modules to be added, which would probably be simply by sticking teh dlls in a 'modules' directory other coders could add functionality such as compression, EQ, time stretch or whatever else. Those functions would appear inside the list of available processes as entirely native.

I should probably mock up the basics of a UI as it'll be a damn site easier than trying to explain it all.

[valley]

Oh, BTW - the hello world demo compiled first time following your steps from start to finish.

[Robert Randolph]

Sounds like a good idea... and easy to do... My involvement in the project will be a bit retarded at first... as Im a linux C programmer.. not a windows C++ junkie Both area's I need to brush up on a lot.

Im certainly in for it though.

[Robert Randolph]

Oh, BTW - the hello world demo compiled first time following your steps from start to finish.

Ahh good.

That's a sign jules...

[Robert Randolph]

If you can get the basic UI done... I think I have a handle of the basic editing techniques. Im still having a bit of trouble getting a grasp of polymorphism in this context (modules)... Im so used to just using linked-lists for anything like this. But from what gather C++ has a more elegant method.

[sojuman]

Robert, thanks a lot! I finally got JUCE library to compile following your instruction. But, I can't get the example to link correctly. I get the following error message:
----------------------
25 C:\Dev-Cpp\Makefile.win [Build Error] *** multiple target patterns. Stop.
----------------------

Before this error, some of the "important (?)" log are as follows:
----------------------
OBJ = "D:/juce/projects/example project for Win32/Main.o" $(RES)
LINKOBJ = "D:/juce/projects/example project for Win32/Main.o" $(RES)
LIBS = -L"C:/Dev-Cpp/lib" -L"D:/juce/bin" -mwindows -ljuce -lmsvfw32 -lwinmm -lrpcrt4
INCS = -I"C:/Dev-Cpp/include"
CXXINCS = -I"C:/Dev-Cpp/include/c++/3.3.1" -I"C:/Dev-Cpp/include/c++/3.3.1/mingw32" -I"C:/Dev-Cpp/include/c++/3.3.1/backward" -I"C:/Dev-Cpp/lib/gcc-lib/mingw32/3.3.1/include" -I"C:/Dev-Cpp/include"
----------------------

I'm suspecting step #9, because when I opened new project, it loaded a main.cpp automatically (default behavior?). So, I deleted this file from the project and loaded the main.cpp from the example location shown in your step #9. Am I already messed up at this point? I seem to have gotten stuck at the same point as ModuLR once did.

Can you tell what I did wrong from the log message? And again, thanks a million! I would never have gotten this far on my own.

[NiallM]

Here's the current plan:...

That sounds really cool . My copy of Soundforge XP is getting on a bit now, and I could definitely use a better audio editor. I'd be willing to help out if I can find the time (though I'm pretty busy at the moment ...).

- Niall.