dRowAudio - Now Under MIT Licence


#1

I’ve just changed the licence of the dRowAudio to the slightly more permissive MIT. In reality this doesn’t make a lot of difference but just frees up a bit of the admin involved. Basically you you now use/trade/modify it as much as you want so long as you keep the licence in tact and don’t take credit for it.

I’ve also streamlined the way to include the module in the JUCE module system whilst being able to still update from Git. This involves creating a symbolic link as described below:

  • pull the tip (see sig)

  • add a symlink in “juce/modules” to the actual dRowAudio module folder “drowaudio/dRowAudio”
    (nix: ln -s TARGET LOCATION, win Vista+: mklink /d , winXP: fsutil hardlink create or Junction)

  • open the demo project in Introjucer and set the “Local JUCE modules” location, save and go

  • Additionally on Linux, if you don’t have cURL installed in a system-wide include location, disable it in the dRowAudio module settings and remove the linker flag in the exporter. It should all build first time.

Eventually I want to separate the module source into its own repo and then subtree it in to the other demo based repo but I need to get all this working cleanly first.

Enjoy!


#2

Awesome!

I think you’re downplaying the importance of this. Anyone who has paid for a JUCE license can use dRowAudio in their commercial products now. This is why I made VFLib MIT Licensed.


#3

:smiley:


#4

Hi Dave…

I hope that doesn’t affect my work of SCPlayer … Right ?
Or shall i also changes anything there ? I have already given credits to You for DrowAudio and Jules For Juce …
And same as you all code on GIThub, SO I guess I won’t have to change in there …

btw good work and congratulations , though i don’t understand licensing things much…


#5

Hi acn,

Your right, the changes to the licence wont affect SCPlayer as it’s open source and you’ve appropriately credited the source code.
Thanks for the support.


#6

For what its worth I thought I’d let everyone know I’ve done a little bit of JUCE module spec hackery so that the root directory of the module can now be used as a JUCE module folder. This means you can just clone the repo, and drop it directly into your ‘juce/modules’ directory. The Introjucer will now correctly pick this up as a module. This means you can now pull changes to the repo without needing any symlinks etc. to the module’s source in the ‘drowaudio/dRowAudio’ subdirectory.

This will be easier to maintain rather than splitting the main source from all the extras and demo etc. Hope it all makes sense, I know a few users were after this. Any questions please ask.


#7

Hi Dave,

I am trying to use drow::SampleRateConverter to upsample a 16knz AudioSampleBuffer to a 44.1k AudioSampleBuffer and am coming across a strange issue. If I try to write the original AudioSampleBuffer out to a wave file using AudioFormatWriter::writeFromAudioSampleBuffer or writeFromFloatArrays the output file is just fine. However, once I pass the AudioSampleBuffer into drow::SampleRateConverter, upsampling it into a preallocaed output buffer (called upsampledTTSBuffer) like so:

sampleRateConverter.process(soundBuffer.getArrayOfChannels(), soundBuffer.getNumChannels(), soundBuffer.getNumSamples(), upsampledTTSBuffer.getArrayOfChannels(), upsampledTTSBuffer.getNumChannels(), upsampledTTSBuffer.getNumSamples());

I get in error in AudioFormatWriter::writeFromFloatArrays when it tries to convert the sample data into ints. Any idea how using the drow::SampleRateConverter can be messing with this? I’ve stepped thorough and everything seems good, but can’t figure out why this might be happening.

Any thoughts? Thanks!


#8

Hi jordanh,

Thanks for pointing this out, it had me baffled for a while but it turns out that the process method was modifying the outputBuffer pointers during its processing so on return they were garbage. I’ve fixed this now so they take a local copy. Grab the tip and let me know if it works for you.

Thanks again.


#9

Ah I see, I was squinting so hard at my file writing code, and stepping through your SampleRateConverter andeverything looked o.k, I’m glad I finally asked.
Seems to work now (well, at least compiled); the output buffer I pass in should store the same-rate converted data even to the caller (not just temporarily in process) correct?

thanks for your help


#10

Yes that’ right, the process call will just fill in the output buffer with the sample-rate adjusted data. Here’s what I used to test it:

[code]void resampleFile()
{
AudioSampleBuffer buffer (2, 512);
AudioFormatManager manager;
manager.registerBasicFormats();
const File inputFile ("/Users/Dave/Desktop/dnb160_13 (16KHz).wav");

// read file
{
    ScopedPointer<AudioFormatReader> reader (manager.createReaderFor (inputFile));

    if (reader != nullptr)
    {
        buffer.setSize (reader->numChannels, reader->lengthInSamples);
        reader->read (&buffer, 0, reader->lengthInSamples, 0, true, true);
    }
}

// resample
const int numSamplesRequired = roundToInt (buffer.getNumSamples() * (44.1 / 16.0));
AudioSampleBuffer convertedBuffer (buffer.getNumChannels(), numSamplesRequired);
drow::SampleRateConverter converter (convertedBuffer.getNumChannels());
converter.process (buffer.getArrayOfChannels(), buffer.getNumChannels(), buffer.getNumSamples(),
                   convertedBuffer.getArrayOfChannels(), convertedBuffer.getNumChannels(), convertedBuffer.getNumSamples());

// write file
File outputFile (inputFile.getSiblingFile ("converted.wav"));
outputFile.deleteFile();
ScopedPointer<AudioFormatWriter> wavWriter (WavAudioFormat().createWriterFor (outputFile.createOutputStream(), 44100.0, convertedBuffer.getNumChannels(), 16, StringPairArray(), 0));

if (wavWriter != nullptr)
    wavWriter->writeFromAudioSampleBuffer (convertedBuffer, 0, convertedBuffer.getNumSamples());

}
[/code]


#11

Hello Dave !

I think you have forgotten to write the code of the function “setSampleRate” in the file dRowAudio_PitchDetector.cpp :mrgreen:

I’m trying a few functions from VFLib and dRowAudio these last days, these librairies have very useful functions ! Thanks for the hard work :wink:


#12

Oops, sorry, fixed that now. Thanks for checking it out!


#13

After the LookAndFeel class changes, it became a pure abstract class.

http://www.juce.com/forum/topic/lookandfeel-changes

Should the drow::ColumnFileBrowserLookAndFeel class inherits from LookAndFeel_V2 now?

Is it right also for the DemoLookAndFeel class of the dRowAudioDemo and for "LookAndFeel settingsLaf" in the TransportComponent::showAudioSettings() method?


#14

Hi pacolanciano, thanks for the reminder. Yes, inheriting from LookAndFeel_V2 should keep it looking the same as it did. I've updated the demo to use V3 LAF though as it's a bit more modern and actually suits the demo better.

I've made these changes in the tip now if you want to grab that.

Cheers!


#15

Nice job. This looks like something I'm going to need if I ever get my project beyond the "G'day World" stage.

I noticed that the dRowAudio web site docs still show the license as being GNU GPL V2. --> http://www.drowaudio.co.uk/docs/index.html

I thought you might want to check that out, and also the wiki link there (and in your sig here) seems to have gone away.

 

 


#16

dRowAudio is great, and it's great that it's MIT!

However, dRowAudio implements other libraries that are not MIT. SoundTouch, for instance, is LGPL. Even if I disable DROWAUDIO_USE_SOUNDTOUCH on the Introjucer, SoundTouch classes are still available in my project. Am I missing something?

For now, the only way I know to avoid using non MIT code is to check each class' file for any references. Is there a better way? 

 

Edit: Ok, now I've tested and saw the way disabling SoundTouch on the Introjucer works. Though SoundTouch classes' files are still in my project, the compiler gives an error if I try to instantiate one.