martinal: sometimes i think about the development of Renoise and what the destination is for the team and for the product “Renoise”.
i know there are so much things to do … so much ideas … but Renoise started with midi-features and the number of users of midi/vst stuff is growing strongly. (more great features increases the range of users!)
please don’t say sysex-feature is dependent on the WIP only!
you started with midi-file im/export and a base feature of midi-files are sysex-messages and sysex is very important to control normal synths and so on …
Renoise is a professional software, isn’t it? base features in a professional Software should be implemented completely and professional too, not half-hearted and incomplete - and independent from user wishes or opinions.
Maybe not dependent on WIP only, but as with all other wanted features we will have to make a judgement based on both the need our current users have for certain features, the amount of work it is to design and implement it, how well it will fit into the rest of the program, and wether the feature will attract more users. This also means, like you say, doing features independent of the WIP votes if we decide it’s a good idea.
We have a lot of wanted features on the list, and many very good ideas to follow up. It’s just too easy for us to say “that’s a great idea!” to every proposal. The result of such a response from our side will only be a lot of dissapointed users, because we “promised” to implement it right away (at least that’s very often the way the user will think). So I’ll rather be honest with you. I don’t say we won’t do this, I’m just not promising a time of implementation for now. Nothing more, nothing less.
The general sysex-bank idea is quite possible to do: receiving messages, storing them, editing them manually and sending them on start or on patterncommands.
But a couple of notes on the rest:
Different manufacturers use different checksum algorithms, so this is not that simple. But it might not be worse than having to search the most common manufacturers websites for the info though.
This is a contradiction… SysEx = System Exclusive, the whole point beeing that the meaning of these messages depend completely on the device. So this is simply impossible.
The only way to get close to this functionality is something like you describe later:
I imagine this requires a huge amount of work, first to implement a system flexible enough to cover even a small amount of the possible ways to organize sysex data, then to create devicespecifications for each and every device. Since we’re not a big company with lots of money and employees, this would require users with those devices and very detailed SysEx knowledge to create each device. The implementation from our side would also require testing by a large amount of users with different devices.
But I think we all could live with basic SysEx-Support (reception, storage, edition and sending). I can imagine that this is not a huge task to implement.
Using SysEx-Support, songs don’t sound different anymore, each time I reload my MIDI-compositions. This avoids making personal notes for each MIDI-song to write down for example what attack-time was used for that instrument etc.
For other SysEx-needs there are existing softwares specially made for that purpose. Just to avoid to re-invent the wheel, and to invest too much time and human resources.
I like the WIP-idea very much, but a MIDI application without SysEx is simply not professional. This is not “Full MIDI support”, as it is written in the feature list in the “about”-section.
Hey… I just hit play in renoise, and record in some MIDI recording package (actually I send it to my mate to do as he uses cubase and I don’t know how to use that), hit save and hey presto… a MIDI file. I think even the sync works if you set it up right.
Yeah, great idea indeed. I did it like this several times on the Amiga and nowadays with Renoise. I playback the song in Renoise, record the MIDI-Parts with my external MIDI sequencer.
The samples and VSTi’s are rendered into wav’s. Then I use ProTools as post-production tool to mix the whole song in one piece.
And I even don’t have significant problems with sync.
Or if you cannot record the MIDI parts with a MIDI sequencer (If you don’t have a sequencer or have “device already in use” conflicts), just record the MIDI parts as a whole wav-file (or more wav-files) using the “what you hear” input source using SBLive or external MIDI Device Line-Out → Soundcard Line-In as input source.
There are quite a lot of work-arounds to “export” MIDI tracks, until the MIDI export feature will be implemented.
IMO I think looking at the way ztracker (ztracker.sourceforge.net) is a good way to go on this -
in short; exporting each discrete instrument (as opposed to track) to a midi channel …
as far as handling of the internal sampler/fx - nothing to be done here; these would just need to be exporting as independant .wav files which could be imported alongside the midi tracks into your host of choice (e.g. Cubase) -
Christopher Micali is the lead dev of ztracker; I would wager he might be able to shed some serious light on how this could be handled if Martinal, you felt like contacting him - just thought I’d mention it.
Midi Export is a fairly big deal for me as well; it’s a top-of-the-list feature in my book.
Export each Renoise Track to a separate MIDI Track (using only channel 1)
Export each Renoise Track to a separate MIDI Channel
(also using multiple MIDI tracks if necressary)
Export each Renoise Instrument to a separate MIDI Channel
For those who do not know:
Each MIDI track stored in a file corresponds to one MIDI stream,
ie it has it’s own set of 16 channels. A MIDI file can contain an
unlimited number of tracks.
He’s still developing? I thought he scrapped it… I guess they’re noodling with zt/2. I still remember the pre-alpha jpg.
Instruments to seperate channels, using multiple tracks as necessary seems to cater for most things. Also, (when importing,) what about having a default instrument mapped to each track? If a note is played with no reference to an instrument, use the one preceeding it (as today), but if nothing preceeded it, use default. Maybe this has been covered, I’ll read the whole thread next.
yea he’s still doing dev but not so much - which is a large bit of what made me switch over to renoise (ztracker is awesome but no plans to implement internal audio and no plans to import midi - and no update since june, 2002) -
but the reason i’m so happy with each instrument to a midi track as it imports so cleanly into cubase; (file, import midi, you’re done) then each instrument can be recorded separarately and mixed along with your exported renoise audio tracks… woot… can’t wait for this feature, hope it gets there!
There is no such thing as a MIDI note with or without “a reference to an instrument”. A MIDI channel has a selected instrument (patch) at any time, and all notes on the channel use the current instrument. Or do you mean something else?
I mean when importing to Renoise, that a conversion will not have every note on a track refer to an instrument, but instead have no reference and then have it specify a default instrument for each track (so that it will conform with the MIDI standard). I guess this is a given, so maybe I shouldn’t have mentioned it. I think it would be a beneficial thing to actually hide the instrument # (like volume and panning), and not have it inserted by default, when entering notes.
Now I get you. Actually, I’ve been thinking about default instruments for tracks before, as a feature indepentent of MIDI usage. It’s common to use one VSTi or other instrument only in many tracks, so this can save both screenspace (hiding all instrument columns in a track) and work (you could switch between tracks and don’t have to think about changing instruments).
Martinal …
now some days are gone … and i ask myself … in wich way midi import will be managed in v1.3 … every midi-channel in a midi-file into a seperate track or mixed/user definable import or what?! … how things stand at the moment relating to midi-import???
Sorry, you’ll have to wait a bit more…
I’ve been working on other stuff in Renoise until now.
Some basics are in place, but these issues are the next step.