Site navigation

Extended ejuce library project

Useful Tools and Components
#1

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)
  • RandomPool (a pool of numbers taken randomly)

database

  • Query (callback class for your query operations)
  • Database (easy sqlite3 wrapper)

math (for 3d)

  • Vector (3d vector)
  • Matrix (4x4 transform matrix)
  • Quaternion
  • Box
  • OrthogonalAxes
  • Face

* neural network *

  • Neuron
  • NeuronLayer
  • NeuralNet

* scripting *

  • ScriptableEngine (gamemonkey wrapper)
  • ExpressionValuator (for computing expression string

* services *

  • 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)
  • OggAudioFormat (add ogg/vorbis audio decode/encode)
  • GenericAudioFormat (add other minor wavefile formats through libsndfile)

* audio component blocks *

  • Phaser
  • WaveGuide
  • Limiter
  • Compressor
  • TubeAmp
  • LinearEnvelope
  • ExponentialEnvelope
  • FIRFilter
  • SVFFilter (single and double sampled)
  • FastOscillator
  • LFO
  • MapMapSampleBuffer (similar to audiosamplebuffer but mipmapped)
  • MipMapOscillator (resampler wrapper)

* spectrum (through fftreal) *

  • SpectrumSource (handle spectra buffer manipulation)
  • SpectrumSourceChannelInfo
  • SpectrumManager (handles audio <> spectra conversion)

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 :wink:
  • all the classes should give a good layer of abstraction and extreme flexibility.

lou

#2

Some really cool ideas in there.

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?

#3

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:

  1. i don’t want to dirty juce codebase
  2. 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.

if you want subversion it… just http://developer.berlios.de/projects/ejuce/

however thanx

#4

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…

cheers

#5

[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…

cheers[/quote]

Interesting idea… I’ll have a think about that.

#6

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).

just to throw some ideas in it :wink:

#7

ı am mostly interested at:

  • 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

I desperately need cross platform IPClient, IPServer, UDP (and SSL versions). I would be more than glad to help on any of these.

My other priorities are:

MDI,
Toolbar,
Grid,
Spreadsheet
More sophisticated TreeView and ListView (with headers and such)

1 Like
#8

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…

so ? no other cod3rz interested ?
lazy people :wink:

#9

Looks nice.

As for your containers though, are you just going to wrap the stl classes that do the same things?

The database would be nice. An integration in classic OO structure would be nice for MySQL and Postgre.

The math would of course be useful for things like the OGL component.

Make sure to abstract out the scripting so support can be added to others without needing to rewrite code.

Regex would be useful.

Networking: don’t rewrite things that are already out, I’d recommend wrapping something like HawkNL.

Looks nice, will help when I can.

#10

not much of a friendly attitude hah?

I am interested in the classes and I can help with the GUI components etc.

#11

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.

Good luck!

#12

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…

#13

oh aydins :wink: i was just joking…

#14

:oops: I was just over sensitive.

I just checkedout eJUCE and will start to play with it.

#15

ok sorry man :wink:

which subversion client u using ?

#16

the step for including it inside a juce project is (if you’re using vs express on win is more simple):

  1. download juce
  2. unpack it in a directory of your choice
  3. go to the juce’s projects subdirectory
  4. create one called ejuce
  5. go into it
  6. checkout subversion trunk with svn checkout svn://svn.berlios.de/svnroot/repos/ejuce/trunk
  7. open your solution or workspace for juce
  8. add the ejuce project
  9. make the juce example project have the ejuce dependancy and ejuce to have juce dependancy
  10. substitute <juce.h> with <ejuce.h>
  11. tweak some

well it lacks the tests subdirectory… wait i’ll post a couple

#17

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. :slight_smile:

#18

TortoiseSVN, it’s very handy

#19

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.

  1. 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.

  2. 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.

best

remy

#20

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]