Hi!
I’m pleased to share with the Renoise community the availability of the open source project NRenoiseTools on codeplex.
NRenoiseTools provides a .NET collection of tools to easily manipulate XRNS Renoise Song and XRNI Renoise Instrument File Formats.
This project is composed of :
A Common library NRenoiseTools that contains almost everything to easily manipulate XRNS and XRNI files in any .NET Languages
A List of tools to convert, extract Xrns / Xrni Renoise files. Currently, NRenoiseTools supports the following tools (if you want to add your own tools, let me know)
o A Xrns2Midiconverter able to convert a XRNS song to a Midi AMF 1/2 File format.
o A Xrns2Xrniextractor able to extract all the instruments from a song and save them to independent XRNI files.
The XsdRenoiseParser specially developed to build an optimized XSD based on the original XSD Renoise Model files (RenoiseSong, RenoiseInstrument, RenoiseDeviceChain).
Features
Supports for multiple platforms : NRenoiseTools can be used on Windows, but also on Linux or Mac (using the Mono 1.9.1 project)
An optimized Renoise model extracted from Renoise XSD Files. The generated model in NRenoiseTools is 10 times smaller than the original XSD model from Renoise.
o Original Renoise Model is slightly extended while still being compatible to provide additional inheritance between XML schema complex types.
o With the use of partial class feature on C# language, Renoise Model is extended with additional methods to facilitate its use.
Use of builtins pre-generated Xml serializers-deserializers for faster loading/saving of Renoise files.
looks like what I did in the past by using a sort of XSD-2-C# converter, but of course with much more work on. Is this already compatible with Renoise 2?
I’m a total noob, when it comes to .net programming. Is there a quick way to get an overview what is exported from the library? Does it work with clipboard data?
It will be updated when Renoise2 is officially released. NRenoiseTools will not support multiple version and will only support the last format of Renoise : i let Renoise handles the complex task of providing compatibility among different versions!
I have just uploaded a CHM documentation. This documentation is only an extract of all the generated classes from the XSD - so don’t expect to have any comments - although you’ll find some comments on extensions provided by NRenoiseTools.
For the clipboard, well everything is probably in it but i haven’t provided any way to faciliate the use of clipboard with renoise data. If this is something you need, log an issue on NRenoiseTools!
I can add an option to handle such feature . You will notice that not all the features in the php version are supported yet
A big thanks for all the work alx. Looks fabulous! If you’ve got questions, ideas about/for the XML format, let me know please (->taktik.AT.renoise.com).
As we do now have a PHP, Java and NET ports of XRNS tools, wouldn’t it be wise to somehow merge them so that we can concentrate more on one of them and making it THE official library?
Now on to business. I had to break my hiatus (i have a forum addiction, it’s evident, i lasted what 48 hrs? haha) to, again, point out that for 3rd party tools “Worse Is Better”. From the document:
even though Lisp compilers in 1987 were about as good as C compilers, there are many more compiler experts who want to make C compilers better than want to make Lisp compilers better.
Now, I’m not opposed to people organizing themselves to work together on stuff, but don’t expect the PHP project to go away. Me personally, I’m less interested in supporting Renoise, more interested in doing PHP scripts for fun. I’m not going to join a C# or JAVA initiative because it’s better for Renoise, I’m doing this for me, not you. I don’t expect others do join the PHP initiative either. That’s fine! Plus, I’m still waiting on progress from danoise and his PHP compatible API. So, there’s nothing wrong with having multiple versions of everything. Furthermore, don’t expect an “official stamp of approval” to magically make stuff happen. See LISP vs C above.
I hope more C# programs happen, and I’m looking forward to testing them on OS X in October (right now I have no time) but “3rd party” means just that; third as in “unofficial” and party as in “fun”.
Yes it’s chaotic and confusing, but frankly since this isn’t my job, I don’t care. For zero dollars, I expect the user to take on some of the burden, not me. Welcome to Open Source.
First, i would like to thank you for providing Renoise Song in xml format. I remember few years ago a suggestion about using xml, you were already thinking about this and this is now great for developing useful conversion tools.
I will share with you my thoughts/questions about the xml format… if we can have some improvement on some fields, it could be great!
I don’t think this is a good opportunity to have a stamped official library… even if i agree that from a developer point of view, open source project are often fragmented and can be somewhat not really efficient, but it’s impossible to satisfy everyone with a single language/platform. You will always find someone that wants to use its own preferred language/platform/technique… sometimes for good reasons (even for freedom! ). I guess this is even preferable, as we can all have benefits from these various sources of creativity.
For example, I did the .NET API because I’m mainly developing with this platform for the past few months (although I was developing in java for the past ten years also…) and I need a .NET API to easily build a conversion of Renoise Song to a proprietary optimized format to embed music in realtime gfx/sound demos… very personal and specific needs, but I found that it’s important to share this with the community, because it can increase creativity!
So for Renoise, my feeling is that the most important official API for manipulating Renoise Song/Instrument files is currently the XSD model. I would expect more an official API inside Renoise, for example for developping plugins inside Renoise itself… but then, i would expect that this API will be delivered by Renoise Team (it is so critical that you must hold the coherence of such an API - The language doesn’t have any importance - it easy to plug a C API to a .NET/Java implem).
Am I the only one to find it a really, really strange/funny coincidence that the mono project is currently at version 1.9.1, with a pending 2.0 release?
Anyway, awesome work alx. If you’re not aware of it, I’ve started a simular project that targets some other platforms (flash/js/php). So far, it’s still pre-alpha, but I’ve managed to parse the song, patterns and instruments, and implemented iterators in much the same way as you have. However, the underlying code, written in haXe, is very different, and, to be honest, a bit of a programming exercise on my part. Also, haxx-rns is meant for quick prototyping, not high/realtime-performance (parsing complex songs with haxx-rns would probably be slooooow no matter what).
So, instead of aiming to merge everything into a single API, I agree with Conner_Bw, let’s keep them separate for now. The best thing we can do, is to align our API syntax and feature set as closely as possible, as it would make any pseudo-code making use of the APIs much more portable.
You can check the resulting XSD file used by NRenoiseTools in the NRenoiseTools-Schemas.zip(*). This schema was generated automatically from XsdRenoiseParser, an application specially developped to parse, merge and apply some transformations to the original XSD from Renoise, while keeping full compatibility.
(*) http://www.codeplex.com/nrenoisetools/Release/ProjectReleases.aspx
Can someone who understands this .NET project please optimize the XSD files included in RC3, all of them?
Ideally, they should not be merged together. Each schema in XSD should be individually optimized, Is this possible? With permission to use in 2.0 Final? ASAP?
I was quite busy and just waiting for the final release in order to update NRenoiseTools!
I’m pleased to release an update of the NRenoiseTools based on the last release Renoise 2.0.0.
The resulting optimized schema is available in the NRenoiseTools-Schemas.zip.
The schema is only 322Ko and is a merged version of the following schemas : RenoiseSong14.xsd, RenoiseInstrument7.xsd, RenoiseDeviceChain7.xsd
The main reason is to be able to support a common object model for song, instrument and devicechain (as it is done implicitly by the current renoise model but not explicitly) : the use of NRenoiseTools is highly simplified with this merge and the resulting XSD is still very small (10 times smaller than the original ones!)
Let me know if you have any problems with this version (although i won’t have too much time to provide quickly a patch if needed!).
Oh, i didn’t know about that. Well, current Xrns2midi supports only value from 0 to 0x7F (not even sure it works with 80) and it maps directly to midi range (0 to 0x7F).
After a check in the doc, if i understand correctly, these values are used in the column:
Because i don’t have too much time right now to apply a huge patch (i suspect that i need to implement lots of new features to supports those commands)
What could be a possible patch to be able to convert a song with these column values? (ignore them? cap them to 7f?)
Any ideas are welcome!
Ok, thanks, right now, i will ignore them and see later what can be done…
I don’t fully understand what you mean by optimized? Is it the same process explained in NRenoiseTools(apart from merging xsd)? If you want to do so, check out the source code of NRenoiseTools, in the Schemas directory, you have a cmd MakeRenoiseModel200.cmd, create a copy and replace it like this:
setlocal
set SCHEMA="C:\Program Files\Renoise 2.0.0\Schemas"
..\Bin\XsdRenoiseParser %SCHEMA%\RenoiseSong14.xsd /out:RenoiseSong14New
pause
And it will generate an optimized xsd for the RenoiseSong14.xsd alone… it stills apply some modifications to the inheritance of some elements… and not sure it will work for all other files, but the idea is here.
If this is not this kind of optimization, you can try to modify yourself the XsdRenoiseParser, although it’s not documented.
It is just not documented, but value 80 is taken for 128 as lots of plugins or MIDI applications / gear send values that range from 1 to 128 instead of 0 to 127.
I had a discussion with taktik about this. I know that Renoise code has already the information (even inheritance) but the difficulty is to modify the current xsd converter. I’m not really confident to integrate in an official release something that has been through an external potentially buggy program… (NRenoisetools looks for similar structure to pack them to a single complex type, but this process is tricky and errorprone)
taktik, if you read this message, what can be possible to do? Is it a huge work to provide this kind of optimized xsd?
