Btw, has anyone considered using the JUCE library in cpp for this stuff? I’ve been using it for a while and since it wasn’t important i overlooked it, but JUCE has it’s own XML core classes.
“XmlDocument and XmlElement - for parsing XML into a tree of XmlElements, which can be easily manipulated and turned back into a text document. The XmlElement class is actually quite a powerful object for storing data structures in its own right, even if it doesn’t need to be externalise”
I’ve decided to release a next version to the public. It’s still not feature complete though. This version includes also the ogg encoder script written by conner_bw, so you can finally compress your XRNS files very easy and without all the usual steps like described in the In:Depth article. Please report any problems you might have here.
Edit: Please don’t extract this version into the same folder like the old one. Delete it first! I’ve modified some folder names.
Here is a screenshot of the new version showing the OGG encoder script in action:
Works like a charm. Thanks to you both to make this happen!
Maybe time to add these to the download-tools department on the frontpage…
This is the kind of stuff we need before this GUI, the scripts can make it to the front page. Please paste the console error. (Click the upper left corner → Edit → Mark → [select] → [enter] → -> Reply to this thread → [ctrl-v]). There are no mysql calls in any of my scripts so I’m not too sure what that’s about.
Also, there are a few more GUI modifications in the pipework. This is probably not the final version. Testing and suggestions are needed.
I think it’s maybe best to wait a little bit, until the first final version is ready, shouldn’t take long anymore.
This should not happen. I’m directly hardcalling the PHP interpreter from the package and pass the -n switch to it, to suppress any php.ini parsing. I’ll have a look at it tomorrow, maybe i’ll find the cause of it.
Can you temporary remove the environment variables and check if this fixes it?
Please do.
Also, my scripts have been updated to correct a few very minor bugs. They should be included in the GUI shortly.
Done.
Another idea for getting some hints might be:
Create a file “phpinfo.php” containing the call written below and place it in the php folder next to php.exe from my distribution.
<?php <br /> phpinfo();
?>
Then run the following from the command prompt:
php.exe -n phpinfo.php >phpinfo.txt
Here is the ouput from my machine, if you need something to compare it to:
…
Hey great utility! Nice work, cheers
I’ve just tried to compress a xrns of mine to an xrns with oggs using your utility on quality level 10, and the outcome features a lot of glitch clipped .oggs 
It is strange, some samples are perfecly converted, some are not. Ahh, now that I look at the original xrns again…the samples are all 44100 khz 24 bit! So can I conclude ogg conversion from 24 bit samples is not yet supported?
Also, the utility created a folder inside the folder where I opened the to be converted xrns (created folder: xrns_ogg_01834c7faccf38bfb47e59edb2230161_Track01 )
Would be nice if this empty folder could get deleted after conversion.
And a pop-up window telling me the conversion is done / finished would be nice aswell 
cheers!
Would be nice, if you could send me a downstripped xrns containing such sample to: info at beatslaughter de
Normally it should except these just fine, i’ll see if i can find a workaround for this.
I’ve finally found the cause of this, will be fixed in the next version.
Being more verbose is on my todo list. 
The conversion is done by an executable known as ‘oggenc’, doing oggenc -h outputs the following:
OggEnc input files must currently be 24, 16, or 8 bit PCM WAV, AIFF, or AIFF/C
files, 32 bit IEEE floating point WAV, and optionally FLAC or Ogg FLAC. Files
may be mono or stereo (or more channels) and any sample rate.
Alternatively, the --raw option may be used to use a raw PCM data file, which
must be 16 bit stereo little-endian PCM (‘headerless wav’), unless additional
parameters for raw mode are specified.
It should not fail in conversion. The script basically just runs a loop on all the files passing it on to oggenc. If it’s failing then the bug needs to be reported to xiph.org. But, before doing that I’d like to see what is going on with your file… Can I also get a copy? Does the console output anything weird?
This is a mystery, this doesn’t happen on OS X, and doesn’t happen on all windows installations… It’s a permission issue that I have spent days trying to figure out, but have not been able to.
For now, click “show console” before launching a script, you’ll get a lot of info flying by that describes what is going on.
Thanks for checking it out and testing!
Let me know if everything works ok now Jonas.
Hey, everything works perfect! It seems like it takes longer to convert now, but no glitches or clipping (and the folders are gone aswel .
Btw I like the randomisation, can spark up a whole new direction on forgotten tracks. Maybe for the future it would be cool to be able to control the amount of randomisation in each track.
cheers
Flac’s are now being decoded/converted into wav files by another command line app before being passed to oggenc, so you perception of it being longer is right on. There’s two steps instead of one now. I sent a bug report via email to xiph.org, your flac files (which i got from beatslaughter) were being converted into corrupted interpretations.
PS: Beatslaughter coded both fixes so props!
this is super- usefull. thanks a zillion.
With 1.9 beta released: One more thing that maybe should be checked in the merge scripts, is that the document version of the to be merged doc matches.
Strange stuff can happen when mixing two document version in one file, so it might be a good idea to disallow this - spit out a friendly message and warn about this?
// ----------------------------------------------------------------------------
// Check doc_version
// ----------------------------------------------------------------------------
// Stringify object by appending to ''
if ('' . $sx1['doc_version'] != '' . $sx2['doc_version']) {
echo "Error: Unsupported, cannot merge different versions.\n";
echo "Save your songs with the same version of Renoise and try again.\n";
obliterate_directory($unzip1);
obliterate_directory($unzip2);
die();
}
I’ll update the scripts page after dinner.
PS: I’m failing XSD validation using RenoiseSong4.xsd (1.9 ships with this but saves as 6) will you be updating this? Or am I doing something wrong?
Thanks.
The schemas will be updated shortly before we are releasing the final version. Its not yet sure if we have to increase the version number (do some fixes, upgrades) until then…
There will be a “RenoiseSong4.xsd” and a “RenoiseSong6.xsd”, if 6 is the final document version number for this release.
I’ve updated the frontend to include conner_bw’s fixes.
@Jonas: Could you test the ogg conversion again on your problematic module? There were some changes made to the code and we’re interested if it’s still working fine.
@Bantai: Would be great, if we could find the reason for the collision. Tried to replicate it here, but no luck.