i think that juce is one of the best framework out there. but it lacks some special stuff that can’t be left away. so i decided to bring juce to a new life, adding and wrapping code from my previuos frameworks into a new one called “ejuce” (which stands for extended-juce) with the same coding style (if i’m able to do that of course, but i don’t think i will compete with jules ability… just trying for perfection!!). the library is based on the concept of not modifying the juce codebase (well at least at the moment the mods on it are limited), it will adapt perfectly to it, enabling the developer to just plug a project in the main workspace, add the dependancies to the executable/plugin, change #include <juce.h> to #include <ejuce.h> and voilà ! you can use all the base classes + the new ones in a glance…
actually what is implemented:
containers
CircularBuffer (easy to understand)
LookupTable (easily tableize your functions for better speed improvement)
Service (something like a more specialized thread)
ServiceManager (to add Service class to the os service abstraction)
actually it implements win32 services only but in the future it will handle linux Daemons and MacOsX ?
* text *
RegularExpression (make easy use of regular expression on String class through the use of the complete pcre library)
* network *
Dns
Connection
Listen
HTTPGet
HTTPServer (abstraction)
WebServer with PageGeneration
* image *
BmpImageFormat
* controls *
Joystick
TextSlider
* audio *
TuningMap (scala microtuning support)
BufferOperations (sse2 operations on aligned arrays)
i’m looking for people really interested in complete juce in every part that would help to code, tweak, test, comment, restyle (in juce style) ejuce classes.
the coding directions of the open source cross platform extension library are:
extends audio_source classes, adding useful types of processing components (audio processors), midi processors and utility for making synths and effects working in time and spectrum domain.
more audio/image format types
adding visual components: every type of user interaction / display visualization tools (especially mouse/keyboard controls)
special network classes support for writing servers, clients
optimized containers like stacks, queues and such…
text manipulation classes
wrapping and support of scripting engines
extend internal database support
add 3d graphics opengl support and math objects/classes for it
make use of good external libraries if possible (like the ones for doing ffts, mp3-ogg decoding,…), instead of reinvent the wheel, just make use of the bicycles out there
all the classes should give a good layer of abstraction and extreme flexibility.
One or two of them are on my to-do-list, though, so careful not to do any unnecessary work! I’ve got some Ogg and Flac audio formats that I’ll release if I can find a neat way of including them (they need the ogg and flac lib files).
And before you get too deeply into writing AudioSource objects, be aware that I may rework those classes soon. I’ve got a slightly different, far more powerful set of classes that do a similar thing, but which can also handle midi input, audio recording and monitoring, pooling background tasks, etc., but I need to have a think about the best way to add them to juce.
And you mention doing a http get, but did you know there’s already one available in the URL class?
thanx jules, i’m sure i’ll do any unnecessary work cause i don’t know what are the future plans for juce. i’m integrating some older work i’ve done in c++ in the framework before i port also my applications but:
i don’t want to dirty juce codebase
i have no version control over it
so i’ll stick with another project library that i hope will be contributed by some more than one people, shared with others without have the hands locked waiting over the releases of the codebase library.
i’ve adopted your style, if is not a problem just to make ejuce stick togheter with its father (but in the coding style much more work is to do).
for the dependancies i’ve ended in creating apart from “ejuce_core” and “ejuce_appframework” the directory “ejuce_libraries” in which i put every dep i need. but without lib files, i always put the sources (if available).
the url class i’ve seen, but i ported my classes from another project of mine so i have it with my package, probably i’ll keep it off since there is the other one. anyway it’s in there…
for sure your audio_sources method isn’t the complex one, but is a matter of converting a bunch of functions when you rewrite the audio classes.
what intrigue me lot is to have in parallel with the audio_sources classes the spectra_sources, treated the same way. so you can process the audio data, then convert to spectral data, process it with a similar class interface to the audio (with channel info and such), then convert it back to be processed furtherly in time domain… i don’t know what is the structure of the new audio engine but i think you should take this into account when rewriting the interfaces…
[quote=“kraken”]what intrigue me lot is to have in parallel with the audio_sources classes the spectra_sources, treated the same way. so you can process the audio data, then convert to spectral data, process it with a similar class interface to the audio (with channel info and such), then convert it back to be processed furtherly in time domain… i don’t know what is the structure of the new audio engine but i think you should take this into account when rewriting the interfaces…
what i have done is just have the spectral_source to process with
getNextSpectrumBlock() a:
[code]struct SpectrumSourceChannelInfo
{
/** The magnitude and frequency buffers that holds
the spectral data. (actually AudioSourceChannelInfo::sampleSize/2 /
AudioSampleBuffer magnitude;
AudioSampleBuffer* frequency;
/** The number of samples in the spectral data. */
int spectrumSize;
};[/code]
then the SpectrumManager will instantiate an internal
SpectrumSourceChannelInfo in prepareToPlay (cause then it’s known the size of the block to process), then passed and AudioSourceChannelInfo it will convert forth and back:
[code] /** Direct fft from an audiosource block to a spectrumsource block */
void directTransformAudioBlock(const AudioSourceChannelInfo& info,SpectrumSourceChannelInfo& spectra);
/** Inverse fft from a spectrumsource block to an audiosource bloc */
void inverseTransformAudioBlock(const AudioSourceChannelInfo& info,const SpectrumSourceChannelInfo& spectra);[/code]
without having to allocate memory in the audio block.
i use also a friend class SpectrumManagerWrapper (friend to the manager) that could make you avoid to be limited to use a single fft library: you could make the wrapper call fftreal instead of fftw3 or whatever library you need without dirtying your includes with external dependancies (this is what i’m trying to make for all the dependancies i have).
i don’t understand if you want to help or you are only interested in the classes. You want to contribute to ejuce ? just grab a copy of juce, start learning how to code in a clean, understandable way, after some months of study grab a current revision of ejuce from berlios subversion repository and see what there is in it, what it lacks and start adding, extending, tweaking, commenting or bugfixing the classes, send the modified version to me and and i’ll revision’em in the repository after testing the changes. if you contribute a lot and you working good i can add you to the developer list.
actually you can find the svn repository @ http://developer.berlios.de/projects/ejuce/ or better you can
svn checkout svn://svn.berlios.de/svnroot/repos/ejuce/trunk
with any svn client out there…
An ambitious project.
The audio components mostly seem a little to high-level to be interesting to me though. Circular buffers and tuning file support, I could use.
thanx… but have you looked at the repository ? ehehe
no they will be alike the stl classes but integrates well in the juce style classes. these kind of stuff isn’t good to be wrapped (as you need speed on core classes like a stack or circular buffer). heavy inlined and easy to use.
actually i’ve just made a sqlite3 wrapper for holding internal filebased database, with an interesting way of making queries… i would like to do a sort oo abstraction to let you connect to whatever database you want (via odbc or specific db api). yes mysql, postgre oracle are the starts.
yes this is the most interesting part. i’ve coded myself some years ago a 3d studio model visualizer and i would like to make it working under juce. but then is time to recode the math and all the classes in a clean and well documented way (also vectorized if possible).
the scripting is based on gamemonkey and is working nicely. the only thing is that i have to manually build wrapper classes around the juce ones, and this is a slow process… slowly integrating…
there is a good pcre wrapper in the ejuce actually that let you find regexp on juce String returning you the indexes of the occurrences so you can slice up the strings as you like (this helps a lot cause i’m making HighligthingTextEditorComponent). but i’m planning on a more powerful version with the possibility of having not only the indexes but the slices of the string directly…
nice one, pretty good and powerful (a bit dispersive, tho)… but then i have already coded my own classes years ago… working already ! just 7 classes for making everything in a cross platform way without dependancies… with these you can setup a simple html webserver with get/post support and basic/proxy authorization and error checking in ~50 lines of code… but not only that !
anyway i’ll post the passages to correctly download the files and plug’em into the juce project soon…
For database abstraction, I’d recommend something like SQLObject’s query types, obviously not the entire class structure as C++ is too limited, but the query structure could be pretty nicely duplicated.
Heck, to go all out you could add python as a scripting language (I’d help bind native juce classes if you wanted it to go both ways, wouldn’t need to, to access python objects though) and access SQLObject, with all its power, directly. Even use Python’s webserver (CherryPy/TurboGears) to do your webserving things. If you added Python as a scripting language that you can call into, it is amazingly powerful and very easy to use.
well, your juce extensions looks very interresting and I’d be very happy to use them.
however while browing the sources, i’ve noticed at least 2 issues about copyright and licensing.
you’ve modified smbPitchShift.cpp, the phase vocoder code by Stephan Bernsee, which is released under the Wide Open License which and states that you can modify it provided that the copyright notice and license appear in all source copies.
you have also modified the LFO class I posted to musicdsp.org some time ago which is public domain and just states me as the author.
in both cases you changed the license to a GPL license and removed the authorship.
appart from the fact that you infrige the WOL, it’s just not really fair to the authors.
while looking at the online svn repository,
I’ve seen that you also added Ross Bencina’s Granular synthesis toolkit which is GPL, but also removed the copyright.
here is the original one
Ross Bencina's Granular Synthesis Toolkit (RB-GST)
Copyright (C) 2001 Ross Bencina.
email: rossb@audiomulch.com
web: http://www.audiomulch.com/~rossb/
This file is part of RB-GST.
RB-GST is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
RB-GST is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with RB-GST; if not, write to the Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
and here is what you’ve put to replace it
This file is part of the eJUCE library
which is based on Raw Material Software ltd. JUCE
eJUCE can be redistributed and/or modified under the terms of the
GNU General Public License, as published by the Free Software Foundation;
either version 2 of the License, or (at your option) any later version.
eJUCE is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with eJUCE; if not, visit www.gnu.org/licenses or write to the
Free Software Foundation, Inc., 59 Temple Place, Suite 330,
Boston, MA 02111-1307 USA
I’m for not reinventing the wheel but you should really leave the original copyrights to their authors.[/code]
i was just joking…