Home | ER-101 | ER-102 | ER-301 | Wiki | Contact

Can we save slices?

Again, my error, I’d conflated the two “j” names. :blush: apologies both!

And that could be already perfect.
Is it saved in a specific file?
I guess it is, in the .lua? Right?
I can copy it multiple times and edit it and save each preset of unit for each grid if slices prepared. Why not.

Wouldn’t it be possible to create an option (enable/disable in global settings?) for allowing WAV user to use proper WAV standard markers as slices?

I (we?) really miss this.
That wouldn’t be perfect as you often explained, @odevices, because indeed it would mean that if you want different slices grid for the same sample you need to duplicate sample… But maybe a temporary solution?

1 Like

I must say that I’m not fond of having to duplicate files either

I wouldn’t like it and wouldn’t do that.
But that would just allow me (us) to slice using whatever software that push markers within WAV and use them directly.

Slices are saved in *.slc files that are stored in the same folder with the associated WAV file. These are non-editable binary files at the moment until I figure out a more permanent solution for a good audio marking file format.

We talked about this before here:

Slice using computer?

AFAIK, the only “standard” marking support that WAV has is the CUE chunk:


Supposedly Reaper lets you edit these but I haven’t tried it yet and I don’t know of any other programs. What software are you using that allows you to edit the CUE chunks in a WAV file?

I agree that the WAV-embedded CUE chunks would be nice to support as an importable format but it is not a good format to work with since editing slices means editing the WAV file. As far as I can tell, there is just no obvious standard for audio meta data supported by a wide array of programs to leverage, unfortunately.

So the best route I’ve been able to identify is to store slices in a separate file that uses simple extensible and open format based. If someone wants to go ahead and design such a file format then I will gladly implement into the ER-301 firmware. Otherwise, we have to wait until I get around to it.

thanks @odevices for your answer.
yes I read the other threads.
MakeNoise’s Morphagene provides that and this is very useful. I don’t compare MG and ER301. But that’s just very very easy.

I know that not all editors can read the “markers” involved in their implementation. Reaper, TwistedWaves etc do. Audacity doesn’t.

I don’t know implementation they decided to do (but I’m sure you already know all about it. if not a short question to Tom Erbe would help). afinfo command shows that:

Not even sure if it is a proper standard at least it works fine.

I’ll check that slice separate files.
I don’t have my ER301 here at home as my studio is not my home.
Do you have one for me here?
I’d LOVE to try to generate .slc files from WAV (maybe from previously done wav markers) and check if it can match my workflow.

1 Like

oops. missed that when I answered.
I guess binary format is for easy process (read/store) on the devices during manipulation.

In addition to CUE chunks, WAV file have SMPL chunks that include loop start and end and other useful metadata. I understand the rationale for keeping the metadata in a separate file, but it seems that a large number of sample oriented software is content with WAV’s embedded metadata.

There is an advantage to using the embedded metadata: your slices would be legible to other software.

1 Like

So we have Reaper and Twisted Waves mentioned so far. Sounds like you know of others. Please let me know what they are. :man_cook:

I’m certainly aware of this effect :nerd_face: However, I’m pretty sure that going forward the ER-301’s native working format will be a separate file using some kind of human-readable format based on XML or JSON or similar. Any support for the meta-data embedded in WAV (or AIFF upcoming) will be available only in the import/export UX.

Sounds like this achieves the goal of having the ER-301 become fluent in WAV semantics, which is all I was hoping for. I’ll send a longer list of CUE/SMPL aware software tomorrow.

1 Like

Audacity devs claim the contents of SMPL chunks are inconsistent between manufacturers.
Here’s an example of this, from SoundForge and CoolEdit:
Similarly, some apparent confusion about the relationship between SMPL chunks that do or do not include the CUE chunk:

This open source sample editor for the Electribe supports CUE/SMPL chunks.

The open source Loop Auditioneer supports these chunks.

Nick Appleton’s Autoloop supports SMPL chunks.

A WAV format validator:

A WAV metadata dumper:

A workflow that some folks seem to like is using Autoloop to create a bunch of markers, and Loop Auditioneer to remove extraneous ones.

1 Like

So what do you think?

  • On the import side, any cue chunks found should be blindly re-interpreted as slices.
  • On the export side, just write the slices out as an array of cue chunks.

And let the user figure out the rest? I’m more than happy to do this but at the very least some disclaimer is probably necessary due to the lack of standards around how cue/smpl chunks are interpreted. I do need to protect myself from users coming along saying “Hey, your slices are not loading in my software X that obviously you should be supporting because everyone is using it.”

1 Like

MakeNoise chose a way. Not every editors can handle this.
You can integrate everything in the equation but maybe you can also drop some constraints and do something that will be “the most compatible” considering all these constraints.
I think this would be better to provide a way to make slices computer editable “on many” editors than slices not computer editable.

I thought Make Noise slices were only compatible with Reaper?

I thought that also, or at least Reaper and Amadeus Pro, but I saw recently a tutorial that suggest that the markers in Logic were also compatible with Morphogene. I can’t confirm that as I don’t have one!

Edit: found the video https://www.youtube.com/watch?v=_StgzcWCkVI

Each program deals with the import and export of this marker/slice/splice information in such different ways. I think in terms of support and documentation I would need to draw the line somewhere reasonable. Suggestions?

I wasn’t suggesting a necessity or preference, just that I had discovered some different information than I had in the original thread that you mentioned above about slices.

As all of the information suggests above, it will be very difficult to satisfy everyone as there will be people with different software preferences which may or may not support the final decision made.

Given those difficulties I’ve been content to work with the knowledge that slices in the ER-301 are those of the ER-301 and try to limit my relationship with computer in that context. I can certainly see the attraction for people but have landed in a modular over there, computer over there manner of working (in part to limit microsd card handling but also for aesthetic reasons).

1 Like