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?
First, great work alx!
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.
Good times.
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.
BTW: Yay! Post count…
BTW, i have just found the project Phalanger - a PHP Language Compiler for the .NET Framework.
It seems really easy to access any .NET framework… Check this article.
Such project is also available for Python Language with .NET framework : check IronPytthon.
I’ll try to post some samples using NRenoiseTools from PHP or Python. Could be interresting…
Ok, I just woke up and for the first time noticed that there are 14 MB of schemas as of RC3… 
Alx, I read your project pages and noticed you already optimized the schemas?
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?
Schemas:
https://forum.renoise.com/t/xml-schemas-for-renoise-files/18684
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?
Can’t someone else do it? -The Simpsons
Hi,
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!).
Anyway, hope this help! 
BUMP
I have added a little citation to this project on English Wikipedia page.
Thanks!
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!
Hi me again.
I downloaded your optimized and combined schema. It’s cool, but not what I’m looking for.
What I want is the a duplicate of all the contents in, /Applications/Renoise.app/Contents/Resources/Schemas, optimized. i.e.
108K - FilterDevicePreset1.xsd
83K - FilterDevicePreset2.xsd
289K - RenoiseDeviceChain3.xsd
661K - RenoiseDeviceChain5.xsd
648K - RenoiseDeviceChain6.xsd
736K - RenoiseDeviceChain7.xsd
33K - RenoiseInstrument2.xsd
44K - RenoiseInstrument5.xsd
45K - RenoiseInstrument6.xsd
48K - RenoiseInstrument7.xsd
2M - RenoiseSong10.xsd
2M - RenoiseSong14.xsd
1M - RenoiseSong4.xsd
2M - RenoiseSong9.xsd
I want to reduce the filesize of what’s already there. Each and every file. Not improve on the method of representation by combining them.
Is this possible with Nrenoisetools?
Could the results be used in the next version of Renoise? (i.e. it’s not GPL…)
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.
Basically, this is what I want. (I don’t have a .NET environment, nor do I know any C#, so I have no idea if this is possible)
XsdRenoiseParser %SCHEMA%\FilterDevicePreset1.xsd /out:FilterDevicePreset1New
XsdRenoiseParser %SCHEMA%\FilterDevicePreset2.xsd /out:FilterDevicePreset2New
XsdRenoiseParser %SCHEMA%\RenoiseDeviceChain3.xsd /out:RenoiseDeviceChain3New
XsdRenoiseParser %SCHEMA%\RenoiseDeviceChain5.xsd /out:RenoiseDeviceChain5New
XsdRenoiseParser %SCHEMA%\RenoiseDeviceChain6.xsd /out:RenoiseDeviceChain6New
XsdRenoiseParser %SCHEMA%\RenoiseDeviceChain7.xsd /out:RenoiseDeviceChain7New
XsdRenoiseParser %SCHEMA%\RenoiseInstrument2.xsd /out:RenoiseInstrument2New
XsdRenoiseParser %SCHEMA%\RenoiseInstrument5.xsd /out:RenoiseInstrument5New
XsdRenoiseParser %SCHEMA%\RenoiseInstrument6.xsd /out:RenoiseInstrument6New
XsdRenoiseParser %SCHEMA%\RenoiseInstrument7.xsd /out:RenoiseInstrument7New
XsdRenoiseParser %SCHEMA%\RenoiseSong4.xsd /out:RenoiseSong4New
XsdRenoiseParser %SCHEMA%\RenoiseSong9.xsd /out:RenoiseSong9New
XsdRenoiseParser %SCHEMA%\RenoiseSong10.xsd /out:RenoiseSong10New
XsdRenoiseParser %SCHEMA%\RenoiseSong14.xsd /out:RenoiseSong14New
Therafter, can the “New” files be distributed with Renoise?
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?
Thanks for the info vV
I wanted to add an optimized Schemas generation for the 2.0 Release, but unfortunately this was not as easy as I thought. Let me check if your optimizer generates valid schemas and then add those to the distribution. I will also try to solve this internally, so you don’t have to apply your external optimizer, for the next Renoise release.
After a long period without any updates, NRenoiseTools is updated to Renoise 2.5. 
Update to 2.6 should be straightforward.
Taktik, if you read this message, It’s great that you did the change for Renoise xsd (compacting using complextype), but there is a small bug in the current Renoise schemas xsd. It’s concerning the way devices are declared:
<complextype name="SequencerTrackDeviceChain"><br>
<all><br>
<element name="Devices" minoccurs="0"><br>
<complextype><br>
<sequence minoccurs="0" maxoccurs="unbounded"><br>
<element name="AudioPluginDevice" minoccurs="0" maxoccurs="unbounded" type="AudioPluginDevice"></element><br>
<element name="BusCompressorDevice" minoccurs="0" maxoccurs="unbounded" type="BusCompressorDevice"></element><br>
<element name="CabinetSimulatorDevice" minoccurs="0" maxoccurs="unbounded" type="CabinetSimulatorDevice"></element><br>
<element name="ChorusDevice" minoccurs="0" maxoccurs="unbounded" type="ChorusDevice"></element><br>
<element name="CompressorDevice" minoccurs="0" maxoccurs="unbounded" type="CompressorDevice"></element><br>
<br>```
<br>
<br>
Should be more write like this :<br>
<br>
```<br><br>
<complextype name="SequencerTrackDeviceChain"><br>
<all> <br>
<element minoccurs="0" name="Devices"><br>
<complextype><br>
<sequence minoccurs="0" maxoccurs="unbounded"><br>
<choice minoccurs="0" maxoccurs="unbounded"><br>
<element name="AudioPluginDevice" type="AudioPluginDevice"></element><br>
<element name="BusCompressorDevice" type="BusCompressorDevice"></element><br>
<element name="CabinetSimulatorDevice" type="CabinetSimulatorDevice"></element><br>
<element name="ChorusDevice" type="ChorusDevice"></element><br>
<element name="CompressorDevice" type="CompressorDevice"></element><br>
<br>```
<br>
<br>
The current version of Renoise is providing a false schema for this part, because It cannot keep the correct order of the devices. It's then impossible to save a correct song with the default schema. NRenoiseTools has been updated and is working well with this patch.</choice></sequence></complextype></element></all></complextype></sequence></complextype></element></all></complextype>I this project still alive?
Not maintained, as I don’t have enough time for it. Though contributors are welcome.
Where can I find resources in 2024? All of the links are broken?
Thanks.