Piano library for ER-301 question

Hi!

As I posted earlier, my ER-301 will arrive by the end of november, but I would like to start working in a project/patch by preparing the samples. The idea is to create a piano patch that will trigger different samples in order to have a full scale of 88 notes without having to use any Kontakt Player or similar software. I’ve seen a couple of videos of people doing this by playing notes with just the ER-301, but I would like to add different velocity layers or even different recordings of the same keys to have a more “natural” or “real” sound of a piano. If I manage to do that, the next step will be to take my own violin performance sounds into the module.

I guess that by puting 3 or 4 layers of WAV files in the memory pool with different velocities and let the 301 trigger each of the different slices depending of a CV value from my planar will be enough … So here we go to the question …

In order to start preparing tha samples, is it better to have ONLY one wav file with all the notes for each velocity level and then trigger the different notes by placing slice points, or to have individual wav files for each note and each velocity?
If the “one file per velocity level” is better, can the mark points from, for example, REAPER be recognised by the 301 like Morphagene does? If not, does the ER-301 save the slice points in an external file that can be edited and linked to another WAV file? That will be perfect in order to export files from libraries all with the same distance from note to note and use the same slice points file …

And, if I’m missing something, saying nonsenses or trying to do something that will not work with the ER-301 please tell me. I already don’t have my unit but I’ve seen so many videos and tutorials that I’m starting to ramble a bit.

Thanks!

I think your best bet would be 1 wav file per velocity level, each containing all 88 notes at that velocity. E.g.

Piano88VelLow.wav
Piano88VelMed.wav
Piano88VelHigh.wav

The way the sample players work you can set the index mode to 12TET, and if they contain 88 slices, this will map to a an 88 key keyboard. If you have 3 velocity layers, I think you’d need 3 sample players, one for each velocity, and would have to route your gate and pitch signals based on the incoming velocity, probably by using Bump Scanner units controlling VCAs.

When you create your slices on the ER-301, it creates a slice file in the same folder as the wav with the same name as the wav file, but with the extension .slc To my knowledge the .slc file can’t currently be created or edited by any other program. I assume it is a text file that could be hand created/edited in a text editor but frankly I’ve never opened one up to look at it.

1 Like

Would you be able to address multiple slices in multiple wav files simultaneously to simulate chords and notes played both together and at varying velocities?

This strikes me as one of those fascinating rabbit holes down which I am glad other people are brave enough to explore.

Sure why not? I don’t think you need to call it a “simulation” either, it’s just called a polyphonic patch! :smiley:

You would take Joe’s recipe and duplicate it per voice + set up all the required CV inputs. If you have a polyphonic midi to CV module like the fh-1 or shuttle control, or a polyphonic sequencer it’s not hard to do. It does usually take a lot of computing power though!

1 Like

Also, I’m not sure I’d spend much time worrying about slicing before hand. If you do a good job of recording the wave file leaving some digital silence in between each sample, the Slice at Onset function will make short work of slicing the sample for you. This slicing was pretty much fully automated:

0002

Yes! I read something about the autoslicing function on the ER-301, so I guess I’ll use it instead of creating the slices with other software.

Once I have my unit I will try to edit one .slc file and see if I can use it with other wav file.

I don’t think this is a very complex project, although I don’t know if the ER-301 CPU will be able to handle it. Basicaly what I will do is to create 3 sample players, one for each velocity layer to play simultaniesly each time the gate is HIGH, and depending on the CV value to open or close dthe corresponding VCA? Right? Then I could duplicate this to create polyphony, I guess …

One more question … Are there any plans to create a computer tool or something to be able to program the ER-301 patches and then export them to be used in the module itself? Like making a MAX MSP patch with the full visual control of the computer screen and then exporting it to the hardware?

Sorry if my questions sounds a little bit stupid … :wink:

1 Like

I was actually going to post the text of the .slc file that the slices in the above image created. But it does not appear to be unicode text - looks like gibberish in a text editor, so it is probably not editable outside of the ER-301.

Your premise sounds right. Not sure how many voices of 3-velocity layered polyphony you’d be able to achieve this way before hitting CPU limits. Would guess at least 3-4, maybe more. I think there is a polyphonic sample player on the list of stuff Brian is planning, so hopefully when that’s done in c++ code, it will be a much more CPU efficient way of achieving poly sample playback.

I’m not aware that any kind of computer based programming tools have been announced or speculated. Right now the Middle Layer SDK is available, which allows you to program a unit on a computer for transfer to the ER-301. But it is definitely not visual - it is LUA code.

best way for high number of samples is:
keep them separate, one folder per velocity layer.
in the 301 go to sample pool.
there you can add files, and you can enable “multi” so you can import entire folders or just flag multiple files.
from there you can load them into one sample player.
in this way the sample player will see all your 88 files as one single file with one slice per note :wink:

Oh! Great to hear that, although it will take more time to prepare the files one by one. Is that method less CPU consuming than creating a single file with slices on it?

1 Like

No, I think you’re better off creating continuous wave files and using the Slice to Onset feature, then.

The method @hyena mentioned would a lot more efficient if you already had each note as individual wave files.

I know when we did this early experiment, I created a MIDI file to play all the notes sequentially at set durations and velocities, and rendered out a wave file, and that made pretty swift work of it. At that early point in the firmware, the auto slicing features weren’t there so @anon83620728 had to hand slice them.

1 Like

ah sorry, i supposed you already had the separate files from a library!

I haven’t the samples prepared yet, so I asked for the best and more efficient way to prepare them for my upcoming 301 unit. I’ll go for a single file with slices …

1 Like