Newbe questions, minor bugs and feature requests

General JUCE discussion
1

Hi,

lets first introduce myself - I am Knutterton, developing professional audio plugins and hosts for serveral years for a big, well known company. Now that I don’t work for this company anymore, I cannot keep my hands off writing music software - so I found the juce framework as ideal basement for all the dreams I always wanted to implement.

I would like to thank jules for his great work. The framework you are providing is outstanding, very stable, easy to use and it saved me 100s of hours - thanks a lot!

Most things do immediately work as expected, but some do not: I don’t know whether it is my misunderstanding or it is a bug - here is my list:

//-------------------------------------------------

The Win32 implementation of readSocket hangs if I use it like this:

String readStream;
int iTimeOut = 100;

while(pConnection->waitUntilReady (true, iTimeOut))
{
char txt[8192];
int iBytesRead = pConnection->read (txt, 8191);
txt[iBytesRead] = ‘\0’;
readStream += txt;
}

because the readSocket function tries to read all the 8191 bytes, even if the server sends less. Do I misuse the read? Should I find out the number of available bytes before I call read()? But then why is the second argument called MAXbytes? I found a workaround that fixes my problem (by commenting out the while loop in readSocket), but I wonder what is the right solution.

//-------------------------------------------------

Next thing: How do I send XML via http? In a previous version of the framework there was a function (URL::createPostInputStream) that accepted all the data I wanted to post as String. The new concept wants me to add the parameters as name/value-pairs, where the values are “escapeChar”-ed and mangeled, so that no server side XML processor can read it anymore. Of course it was easy to work around, but I wonder, how you ment the new concept to work with binary data or xml? I am sure, I am missing something.

//-------------------------------------------------

Next: What is the right way to stop a waiting StreamingSocket? I start waiting in a background thread but when the app shuts down I want to gracefully stop waiting? Currently the framework exits the thread after 3 seconds - which is not exactly nice.

//-------------------------------------------------

Next: The AudioProcessors initial samplerate is set to 0. When scanning, some VST-Plugs ask for the SR and then hang or crash (div by zero-exception) because of that. I suggest to initilalize it to an unusual, but valid value, like 8244. That wont hurt but make the scanning more stable.

//-------------------------------------------------

On Mac the retrieving of the plugin version doesn’t work for me at all (Returns V255.255.255.255 always).
Anyway - I would like to have a general File::getVersionString() function. I implemented it for Win32 and MacOS (I can send it via mail if you like) - Linux is missing. Also I changed the VSTPluginInstance::getVersion function to:

const String VSTPluginInstance::getVersion() const throw()
{
return module->file.getVersionString();
}

which perfectly works for me.

//-------------------------------------------------

The problem I am currently working on is missing text input in the TextEditor-Component under Windows Vista and some vst hosts under WinXP. The TextEditor gets the focus, but it seems to ignore all the key events. I will let you know if I found the reason.

//-------------------------------------------------

I would very much like to help making the juce framework even better - so let me know if I can do anything.

Best, Knutterton

2

Hi, glad you’ve been enjoying using it!

Sockets are actually one of the bits that I’m not totally confident about - I’m not much of an expert on them, and don’t have any personal projects that use them, so a lot of the stuff in there has come from suggestions and requests by more network-savvy users!

…so I’m not entirely positive about what the “correct” behaviour of the read() should be… any heavy socket-users want to chime in here? But you’re right that if the current behaviour is correct, the parameter should be renamed as “numberOfBytes” rather than “maxBytes”.

Good point about sending other data in a http POST - I hadn’t thought of that. I’ve extended it now (but not tested it!), if you want to grab the tip and have a go. Can’t believe I forgot to put that functionality back in after I made the changes…

Re: VST versions, it’s really down to the plugin to supply that value, but how about this:

[code]const String VSTPluginInstance::getVersion() const throw()
{
int v = dispatch (effGetVendorVersion, 0, 0, 0, 0);

String s;

if (v == 0 || v == -1)
    v = getVersionNumber();

if (v != 0)
{

[/code]

But sure, I’d be interested in seeing your file-version-getting code, too - that’d be a nice method to add to the File class.

The sample rate of 0 problem isn’t something I’d heard of before, but maybe it’s better to add a bodge to the VST code, e.g. in VSTPluginInstance::handleCallback():

case audioMasterGetSampleRate: return (VstIntPtr) (getSampleRate() > 0 ? getSampleRate() : 44100);

It wouldn’t be the first hack I’ve had to do to stop flakey VSTs from crashing.

As for the text editor focus, it’s probably because the host is hooking the key events before they get to the plugin. Do a search of the forum for this, because there’s been a few threads about it before…

Many thanks for the bugs + suggestions!

3

Yes, that would help. But I am afraid that some plugs wont re-initialize correctly later - when the original samplerate is set. Thatswhy I always initialize samplerates to 12345 or something like that. But maybe I am just paranoid depending sick vst plugs.

The TextEditor thing happens only in some shareware hosts on XP, but on Vista I have it also in commercial hosts, like Ableton Live. I will try to debug it later today.

What about stopping the waiting StreamingSocket? Any ideas?

Thanks, knutterton

4

Yes, you have to expect the worst of 3rd party VSTs, there really is some junk out there. I used 44100 because that was already my default that’s returned by handleGeneralCallback(), but I guess I could change it to a silly value.

Not sure about the socket thing, I guess that’d involve some platform-specific hackery to interrupt that send() function, but it’d require a bit of research…