Extended ejuce library project

yeah mdsp
sorry for the infringement of your class and of any other, sorry really…
i’ll add the copyright i’ve excluded by running my program to add ejuce stuff on top, killing the other ones.
i’ll fix it asap and checkin the repository

anyway :wink: mdsp i like very much your stuff !

no worry

anyway :wink:
i would like to see this growing and evolving. i see you have made a lot of fft stuff. i would like to delineate something cute for use in juce. something like a frequency processor, where u can write some processing functions in frequency domain and then use 'em in the audio graph like any other time domani processing modules. you sure could help out a bit. look at the SpectrumSource and SpectrumManager… the use is simple but i’m getting some weird clicking on ifft reconstruct of signal. could you give me some tricks ?

anyway… copyright infringement fixed. now credits is given to all the authors.

[quote=“kraken”]anyway :wink:
i would like to see this growing and evolving. i see you have made a lot of fft stuff. i would like to delineate something cute for use in juce. something like a frequency processor, where u can write some processing functions in frequency domain and then use 'em in the audio graph like any other time domani processing modules. you sure could help out a bit. look at the SpectrumSource and SpectrumManager… the use is simple but i’m getting some weird clicking on ifft reconstruct of signal. could you give me some tricks ?[/quote]

Sorry for the delay

IMHO for a general frequency process chain, you should use complex FFT data instead of magnitude and frequency, this id handy to have it like bidule does, but someone might want to use another phase vocoder algorithm or do anything on the fftbins. and this is a more general approach.

to avoid clicks and artifacts, there are several things to consider

  • overlap-add processing
  • windowing on before fft and after ifft by sqrt(window) the second windowing reduces time aliasing.
  • use an hanning window it has the advantage of summing to a constant for 2,4,5,8 …overlap ratios thus not introducing amplitude modulation.

keep in mind that a spectral processing chain should be processed at it’s own rate. there are few chances for audio blocks boundaries to match overlap-add ones.

1 Like

hey, it’s better long delayed then never :wink:
anyway, i’ve leaved the approach to better math people… i’ll continue working on it if i find more time… and my dog still sleep and don’t ask for my late-late night time again… ehe

:wink:

yes I also stopped working too late. there’s a trade-off to find between keeping you girlfriend and working on your own projects after work… :slight_smile:

is ejuce still around? i can’t connect to svn server.

the repository changed, SourceForge tipically changes the svn url every month without dropping a mail.

it is a long time that i do not recompile ejuce, mh helped me keeping in sync with juce till 2 or 3 version ago, so probably it will produce some errors.

If you plan to compile the new version, send me the changed files as well…

hi kraken. as you may or may not have noticed, i did put my CoordinateSystem class on here a few day ago. i’m just thinking about making a 3D coordinate-system for reverb energy-decay-reliefs and the like and i am spending some time on reading up on 3D->2D projection techniques (axonometric, perspective, etc.) - and then: BANG: i stumble over your extended library which already has 3D-graphics implemented. i figured, i probably don’t need to reinvent the wheel then. thanks very much for your efforts. i highly appreciate your enthusiasm and would like to contribute - but i’m not sure about the question, if i can make significant contributions anytime soon. but if you like it, i could adopt my CoordinateSystem-class for ejuce at first. i’m not familiar with svn (isn’t there any graphical front-end for it?), but i seem to have managed to grab ejuce via sourceforge…will look into it in the next days.

yeah, i’ve noticed your classes. nice indeed, and i will use it for sure in a project i have here for measuring stuff…

eh, as i have already said it is a long time that i do not touch ejuce at all. it has some interesting stuff anyway, even if 3D is implemented very easily.
but i don’t know, the ask for collaboration was quite old, and now i’m not seeking help (cause i’m too busy on other personal projects), apart who wants to keep ejuce in sync with every new juce release.

anyway, feel free to improve ejuce !

[quote=“kraken”]yeah, i’ve noticed your classes. nice indeed, and i will use it for sure in a project i have here for measuring stuff…
[/quote]

ah, glad to hear that is is actually useful for someone. if you downloaded early, there may be a newer version online (i improved and cleaned it up a bit and replaced it silently yesterday morning). let me know if you find any flaws.

[quote]eh, as i have already said it is a long time that i do not touch ejuce at all. it has some interesting stuff anyway, even if 3D is implemented very easily.
but i don’t know, the ask for collaboration was quite old, and now i’m not seeking help (cause i’m too busy on other personal projects), apart who wants to keep ejuce in sync with every new juce release.

anyway, feel free to improve ejuce ![/quote]

understood. have also several half-finished projects lying around here. :roll: nevertheless, great iniative. i guess, it will help me making my 3D-coordinate-system either way - either making it from scratch (departing from the 2D one), or relying on ejuce

Hello/Gruess Gott!

I’m really interested in ejuce, but it checks aggressively for JUCE version 1.39.

Is there a more current version than the one at ejuce.svn.sourceforge.net?

Can I comment out the version check and hope it works?

Is there a work-around?

…any reply appreciated…

stp

that check was there just to provide a safeguard against jules changes of the core library. you can avoid the check but you have been warned: probably a lot of classes need to be adapted.

Is ejuce still active and up to date with the trunk of JUCE? It looks like not much has happened on sourceforge or did it get moved somewhere else?

ejuce is actually a dead project. i don’t think i will ever continue to put things inside it as i’ve got a new trunk to play with (much more better organized, and a natural extension for the juce framework) in my jucetice project.

Probably in the near future i will put this extended juce trunk in a public place. For now you can only browse it in the “jucetice” directory here.

cheers !