I have a song I’m working on, but I want to import samples with slice markers that are saved in another Renoise song I have saved? Is this possible? Am I making sense?
Yes, save the instrument as an “Instrument”, an .xrni if you will (not a sample), and the slice markers will follow.
OK, thanks, but I have more than 100 instruments to import, do I have to save each one as an xrni individually before I can import?
Yep
Somebody’s made a Save All Samples From All Instruments tool, has nobody made a Save All Instruments tool??
I have to add I have also always found it weird that you can loads samples from within a saved xrns but not the instruments! Although that would mean parsing the song.xml for the instrument data you still have to look inside the zip to get the samples and surely it can’t be much harder or resource hungry than that process??..
There is no API function for that.
theoretically speaking it could be done, but it would require reinventing the wheel completely.
Something needs to be done. I love Renoise but I just find the whole upper right sample/instrument so limiting and too basic for importing / exporting samples/instruments. Way too basic. I feel like it needs to be expandable.
This is now going to take me ages. I have several songs saved, all of which have hundreds of instruments, and I need all those instruments to be bought together into one song…and I have to do this by saving each one individually? Am I the only one that finds this incredibly annoying?
Why should someone even have to make something to enable a process which should be fundamentally part of Renoise itself.
Renoise is all about sequencing samples, right? But we’re stuck with an incredible basic sample window, whereby I have to download a tool just to be able to export all samples, and there is no option to export all instruments.
Lame.
I doubt you’re the only one who finds it annoying, and I’m sure we can agree that some improvements can be made here.
There’s something very important to keep in mind here: A feature which may seem obvious or crucial as hell to you, will not necessarily be something that everyone needs, or something that others have even considered in the first place. The fact that you have over 100 instruments you need to export/import is actually quite a unique situation that isn’t going to happen every day for most users, so this is not the type of situation that’s easy for us to predict. Most average users are probably just exporting/importing a handful of instruments from song to song, or they manage their sounds in some other way that is convenient for them. But now that you have pointed it out, yes, it does seem obvious that we could have an easy-to-use feature to export all instruments from a song.
Speaking personally, whenever I create a nice instrument I like, I usually export it right away purely by habit, because I know I will probably want to use it in another song later. Then one day when I’m working on that new song and I want to import a bunch of my favourite instruments, I already have them conveniently saved in a folder where I can do a multi-selection in the disk browser and just drag the whole bunch directly into the instrument list. So for me personally this is not a big deal, but this is obviously just my workflow, not yours.
At the end of the day, the dev team is small – tiny, in fact. We’re only human, and we sometimes make mistakes or overlook things. We’re definitely not mind-readers, after all. We added the Lua scripting API to Renoise exactly for this reason – so that others could add their own desired functionality to Renoise, to make up for things that we didn’t think about, or to expand on things that may be lacking. Isn’t it better that we give you the ability to expand the functionality on some level, rather than saying “well, tough shit…”?
Yep, it can be lame when the thing you want is not available. But we do try to listen to the community as much as possible, so you can give us your constructive criticism and feedback – expressing your concerns and ideas in a clear way – and then we’ll consider that for a future update. That’s the best we can offer, really.
For what it’s worth, I would recommend running 2 instances of Renoise side-by-side.
In the first instance, load up your old song with the desired instruments you want to export. In the second instance, you have your new song ready to import into.
Go the first instance of Renoise and middle-click the instrument list on the desired instrument, to simultaneously select it and give keyboard focus to the instrument list, then hit CTRL+C to copy.
Now go to the second instance of Renoise and middle-click the instrument list at an empty slot, then hit CTRL+V to paste.
Repeat this until you have the desired stuff in your new song.
While this is still a bit of a chore, it’s much less of a headache than constantly saving/loading instruments all the time, imho.
I save collections of instruments as xrns files, with no notes or patterns, to use for song templates. I wish it was as easy to get instruments out of an xrns as it is to get a sample, but it works for the moment.
dBlue: Say somebody has been experimenting with one of the various “synth” type Tools created since the scripting language came in. They may have created a few dozen (let’s say 100 to keep with the earlier example) instruments of which they would then like to package and share with the community. Sure they could package the .xrns song file and let the user extract the instruments themselves, but then the user will not be able to prehear before loading easily.
Sure loading up two instances of Renoise and copy and pasting from the xrns is probably the work around that for this example would probably make it the easiest. But it may not be obvious to many and forcing people to have to resort to suck work arounds seems weird to me.
I would say you should be able to select more than one Instrument and then save all selected. Currently this isn’t possible. Not sure if a Save All would be needed in addition to this as you could then just select all instruments to save all.
I also really think it would be nice to be able to load Instrument, not only Samples, from existing songs.
My point was never that you should have to but that luckily, for many operations that have been skipped from the main program, whether by oversight or by decision based on feeling they are too niche by the Devs, we how have the power to program ourselves rather than request and hope get added in the next version, which we have no idea of when it’s coming!
Which is exactly why I attempt to offer workarounds whenever possible 
I’m definitely not arguing against any of the suggestions made here, or implying that people should just suck it up and be forced to deal with workarounds forever. There have been some good points made here, and certainly a few no-brainers that are clear oversights on our part. As always, there are things that can – and hopefully will – be improved. Keep the constructive criticism and suggestions flowing!
Totally agree.
Totally agree with this, also. It’s a slightly more complex problem to solve, though. With the samples it’s a piece of cake, because they’re stored as indexed files within the ZIP archive and we can easily parse those, but in order to find the instruments we must parse the actual Song.xml, which also means extracting that from the ZIP and dealing with the additional overhead involved. The issue is basically how to handle all that crap quickly and efficiently. The obvious thing that springs to my mind is avoiding ZIP in the first place, and simply storing .XRNS songs as standard folders, where we can instantly access everything stored within. This is obviously not quite as elegant as having a single, easily portable file, though.
If we’re exposing the instruments within the .XRNS via the disk browser, then people will probably also want some form of pre-hear functionality as with samples. This is a potentially hideous technical problem to tackle, since the instrument could be anything from a single cycle chip sound with some basic modulation, to a 500MB+ multi-sampled beast, to a hugely resource intensive VST plug-in, or anything in between.
Exactly the points I made when I first mentioned it. There is the advantage that you only need to do any parsing (same I imagine exists for samples within the zip currently) once you expand the song to display the contents, so loading folders of songs shouldn’t be slowed down at all. Only the operation of expanding the contents of the song file. I think people would live with that being a bit slower.
Has it’s pros and cons. I like the self contained .zip. Another option would be to include the Instruments within the zip as xrni, so they have their own xml data, rather than keeping the instrument data bundled in with the song.xml file.
Prehear of xrni Instruments is already pretty poor to be honest! Not sure what I would recommend to enhance it though…
Play c4 at full velocity, would be a start!!!
OK I actually forgot there is zero prehear at the moment!
Base Note at Keyboard Velocity for one Beat duration for Each Sample contained. Or is that overkill?? Also wouldn’t work for purposely detuned stuff…
So dblue now explained that it takes slightly longer time to uncompress and parse the song xml (than just listing files in a predefined folder in a zip). I for one would definitely be okay with this feature (maybe being a optional pref?), and having the browser take a second more to expand .xrns.
Although the xrni format is not that difficult, it’s indeed really a “there’s a hoooooole in the bucket” story then. Not to mention it would probably work a lot less quickly through lua than through native C++ code.
You shouldn’t just go shouting at the program which is quite minimal but on most things it’s got, phat awesome. I’ve also pointed out some things that should be accessible through API calls, like reverse sample, there are a lot more, but not everything can be done on each release, right?
I feel you couldn’t have been less subtle here, or maybe saying this little word ‘forcing’ is just full blown twisting the truth… “forcing to have to resort to suck work arounds” - for that you’d have to go to some other program with actually really mad wack software support. Actual Renoise devs frequent this forum! Supplying everybody with tips&tricks!
PS I think you mean sucky? or how would people give head to a workaround?
In this case the devs imo should definitely settle for only sample based instruments, like, under 2 mb or whatever is necessary to keep renoise semi-responsive.
That’s what it does, only in “post-hear” mode. And I don’t like it at all. In my case at least when I doubleclick a OT xrns I get a fat second or so of deafening noise at what I guess is C-4.
Actually I mean sucH workarounds. Wasn’t trying to say the work around itself is sucky, although the fact you have to do it at all is. But at least they are there!
My dyslexia has a weird form in that I regularly mistake letters that either look or sound slightly similar. The amount of times I write dick and later realise and have to correct it afterwards to disk is almost worrying at times! Then sometimes I have to think about b/d/p letters more than I really should as well…
Note to self: Always proof read things before hitting send! I generally do but sometimes posts slip through. Especially if I’m half way through typing and something comes up…
Good point, but I already thought this through before I made my post. I questioned myself as to whether having an expandable / more advanced sample window which makes importing / exporting samples easier, would be a benefit to only me or ALL Renoise users. I guess that’s open to debate.
Clearly a benefit to all users