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

Sample Player: Slicing Wish

request

#1

This probably falls under a previous post “auto slicing” - but i couldn’t recall if that was based on transients or a set time division. It would also rely on development of a basic utility file editor for trimming a file… (or doing it externally)

I’d love it if after creating a perfect loopable groove (or a loop dropped onto the card) that there was an option in the slicing window to set a division amount and just place all the slices across the file based on the division. Either a user defined number or something generally musical such as 3/4/6/8/12/16/24/32 etc.

This would be awesome with retriggering and CV’ing slices on the fly, especially in conjunction with a clock divider on the triggers for some random yet organized chaos :slight_smile:


#2

I would like to have metric subdivision slices as well as thresholdable transient slices!


#3

I second the wish of giftculture…


#4

+1 on both slice methods

Also, maybe a way to use cv to “nudge” the whole slice grid over left or right would be cool.

(Actually, im not sure if "nudge " has not already been implemented ?)


#5

If the nudge was actually able to create a “wrap-around” with offset slices, then the ER-301 could replace my Ginko sample slicers - which would be nice, as the 301 sounds so good!

Neil


#6

exactly

edit addition:

another thing that would be really neat would be the ability (for example):

have 4 different loops (timestretched to the same bpm/or not) with a different/or the same slice grid on each loop.

a cv control option of able to randomize those slices (of the 4 tracks/loops)with option of monophonic)
then have an option to cv/or hard set mute any of the slices for example on a 4 x 16 grid screen view.

that mixed with probobility would make a really fun situation.
Just throwing some ideas out there.

btw, the er-301, is indeed awesome
the audio quality is superb, and i look forward to all the mangling of it!


#7

Is basic auto sample slicing(based on transients/zero crossings) coming anytime soon? Or has it already been added ?

I have not had time to keep up here and it’s been 3 months, so maybe i missed the feature somehow ?


#8

You have not missed it. Auto slicing (both onset detection and time division types) is still sitting on the todo list. However, the “nudge” idea has been implemented as “slice shift”.


#9

cool ! i need to check that out, thanks!


#10

to all er-301 enthusiasts: first of all, please dont “rake me over the coals” here for asking:

hi again brian. Could you please explain how you are deciding the wishlist for features ? i am an original pre-order supporter of your project but i am not a programmer at all and i see most people that post here are much more advanced than others in this regard. I have also seen others say they are getting lost and having a hard time keeping up. I understand you said about re-writing the framework before impimenting other features, but it seems like you have been doing exactly that and i wonder what the plan or eta on basic auto-slice will be introduced ? Could you please enlighten us non-programmers with your plan, possibly in order of what is your(or whoevers?) priorities will take place ?

I wish i had the time to spend on figuring this thing out all the time and help beta test it all the time, but unfortunately i just can’t(for many reasons in this point of my life).

I am quite overwhelmed and wondering what spot on the priority list the auto slicing features are sitting at on your list of things to do and for what reasons .

Thanks to everyone working on this project, but it has unfortunately gotten too far over my head and i have honestly been waiting for auto slice for a long time(and so have others).

Please do not rip my head off anyone, im just asking. I never claimed to be smart ! Yet i fear this is one of those things only for advanced users…If that’s the case i can sell it to my friend and buy a bitbox or fire up some old reaktor.

btw, also: i can never get any of the patches to work that people post because i have fallen behind in the newer firmwares and no manual so…really wondering if it will be another half year before these things even happen. I hope you all understand where im coming from. I understand i may have made a mistake buying this module, i wouldnt be the first mistake iv’e made haha !

No negativity implied here… peace!

Thanks


#11

Lots of questions here. Let’s see if I can answer them all.

First, let me thank you for taking the time to post your feelings! It’s hard to be critical without sounding negative, yet you have succeeded in doing that. Very awesome!

My software development priorities are in this order:

  1. Fix bugs that cause crashes.
  2. Fix bugs that interfere with users being able to save/recall their work.
  3. Fix bugs that interfere with the use of existing functionality.
  4. Implement features whose absence interferes substantially with the use of existing functionality.
  5. Everything else is cherry picking.

That being said, I admit that sometimes something jumps out of order (especially with respect to 4 or 5) because implementing something immediately while it is being discussed or is fresh in the mind is better than putting it on the back burner and letting it get cold.

The documentation development is happening in parallel over on the wiki but is going slow. I sincerely apologize for that. It is expanding little by little every week.

The framework re-write was completed back in v0.1.x. We’ve been back to the regular cycle of accepting feature requests, prioritizing, implementing and testing for a few months now.

Auto-slice is on the list of definites. It just keeps getting pushed back because of 2 things:

  • The lack of auto-slice is not really in the way of anyone getting to the place where they want to go. It is more of a convenience feature, albeit an important one!
  • Auto-slice has a dependency on fixing how slice data is associated with the audio files. Remember the discussion here: Slice using computer?. I would like to resolve this issue first.

Probably, the most accurate ETA that I can give you on auto-slice is “by the end of this year”. I hope its not too disappointing.

My goal is definitely NOT to target only advanced users. I’m not even sure what an “advanced user” means! :confused: I seriously doubt that any of the concepts in the ER-301 are out of your reach. Clearly, it you are just a busy person without the time to sift through the chaos of this forum to look for answers! So tell you what, when I finally get v0.2.x of the firmware to a stable state around of the end of this month, I will spend a few weeks working on nothing but documentation over on the wiki. Hopefully, that will provide the necessary springboard to alter your perception of the ER-301 to just a collection of simple building blocks.

I definitely feel your pain here. The preset loading system is currently clunky for the following 2 reasons:

  • Dependencies on how each user organizes their files on the SD card.
  • The backward-ness of having to insert a unit (of the correct type) first and then load a preset.

I’m in the process of fixing this. The priority of this exceeds the priority of auto-slice unfortunately.

None taken. Thank you so much! Let me know if I left anything out in my answer.


#12

Thank you! all you say makes perfect sense to me, and i very much appreciate your quick response.
The main reason i had to ask(possibly sounding impatient) is that i am at a point where i must decide what to sell to pay bills. And as we all know life can take a turn quicklike so…
I’ll stay on board as much as i can, surely i can find something to get rid of other than the er-301. I’ll get rid of something else.

Your reply (and work so far) has re-assured me.

Thanks Brian & all working on this.


#13

No problem. Financial advise is way outside my area of expertise, so I will remain silent on that.

By the way, how about you create yourself a thread here just for your questions and confusions with the ER-301? Call it something like “v0ltstarv’s trials and tribulations with the ER-301” and just throw all of your questions in there as they come up. I will attempt to answer them as soon as I can (which is usually pretty soon). Don’t worry about asking duplicate questions because it is your thread. Also, by having a thread all to yourself, you don’t have to worry about whether a particular question warrants a whole thread.

You get answers and I get an idea of what is confusing users in your position (which helps a lot when I’m writing documentation).


#14

ok, sounds good. will do. I have an idea of what i want to do, i will post it after i try doing it again myself.
Thank you


#15

you’ll have to correct me, but right now i see not one issue but two issues that CAN be related to each other(, but do we really HAVE to?!?) :
issue 1: is “how slice data is associated with the audio files” within the er301 and
issue 2: slice data compatibility between ‘alien’ computers and the er301

i got curious and reread the slice-using-computer thread where i found this

issue 1:
fastest read times sounds good to me…

  • how feasable is a solution that reads the duration of a given wav file, computes some time stamps for
    a user defined number of divisions and writes them in that associated .slc file?
    and in order to do so, do you really have to fix “how slice data is associated with the audio files”?
    same goes probably for zero crossing detection and the combination of zero crossing and divisions…

issue 2:

  • generally, and at least to me, the most interesting and probably the most exciting aspect about the er301 is that its developer was brave enough to choose the only two basic formats (PCM/voltage control) that
  1. i am willing to ‘read’
  2. i believe to be sufficient in order to make serious music/noise and
  3. i believe to be (almost) platform agnostic
    combined them with a replaceable/upgradeable computer and some hardware interface
    that gives me access to above mentioned formats (via cv- and sd-card-interfaces) and the algorithms that are correlating
    those formats in infinite ways (via GUI)…
    from this personal perspective it seems somewhat odd to me that the development of the er301 would be depending
    on a standardization issue that (oddly enough) exists in the world of all the other computers…
    to be clear, this is a very personal anxiety and surely is a bit exaggerated:writing_hand:
  • i can perfectly see how it is desireable to make the slice-data-wave-association on the er301 IN A WAY
    compatible to slice-data-wave-association on other computers. though i got the feeling that the best way
    to do so would be to solve above mentioned issue 1 first (but independently of issue 2) and then turn to issue 2 (depending on the solution found for issue 1).
    i.e.
  1. developing the best possible slice-data-wave-association for the world of er301s
    (which probably will have to stick to a machine readable format) and
  2. then developing a (bable-fish-) solution that translates slice-data-wave-associations between the worlds
    of the er301 and alien computers:point_right:

@odevices:

  • do you really have to wait for the babel fish to appear? or can the babel fish wait for you to get ready?
  • and if the fish could wait for you: how bad is the current slice-data-wave-association of the er301 anyways?
  • is it already possible to associate an .slc file of one wav file to another in a manual way by going lua on it?
    (it is obviously not possible via the hardware UI yet…)
  • do the .scl files contain absolute time information or relative to duration? are both approaches possible?
    i’m still curious…

#16

Let’s see. Where do I start? :scream_cat:

As your description shows, implementing the auto-slicing or grid-slicing algorithm itself and writing out the results is not the hard part. The hard part (for me at least) is the user interface to the algorithms and their parameters! A grid-slicing algorithm needs to give feedback to the user by dynamically showing the grid on top of the audio, so that the user can offset and line things up properly. An auto-slicing algorithm needs to expose a “sensitivity” parameter that the user can tweak while seeing the effect immediately on the number of slices produced.

Now you are totally right about the implementation of slicing algorithms and the implementation of slice data formats are 100% decoupled in the software. However, they are very coupled in the UI design. In effect, it is the UI design that is complicating and thus delaying those items, not their software implementation.

So I guess what I’m trying to say is I would like to first storyboard the UI for a whole list of related features before I write the necessary software. In addition to the interfaces to the additional slicing algorithms, I have decisions that need to be made about types of slices and perhaps expanding to include (possibly overlapping) intervals of time (loops, etc.). Should text labels also be supported? How do I present the association of multiple slice sets for one audio file to the user? Should algo-inserted slices be treated differently from user-inserted slices? And so on.

So in conclusion, I probably confused the issues by pointing to that thread which, on the surface, seems to be about slicing on the computer. However for me, the thread is about the question: How do we author and manage meta-data for audio? I should have been more clear about that! :bow:


#17

Hey @v0ltstarv,

First of all welcome :slight_smile:

We don’t do that kind of thing here, there’s a pretty clear set of guidelines for respectful discussion that is sent to everyone in a welcome email:

Please feel free to ask whatever you like, there are no dumb questions, in fact it’s often these kinds of questions that lead to interesting ideas and further development so they are really welcome.

Glad to see your faith is restored somewhat - have fun!!

:smile_cat:


#18

thanks for the elaboration. i find these considerations pretty fascinating and they
certainly got me started. hope that it can enrich the development of all our slicing wishes.

Re: [quote=“odevices, post:16, topic:246”]
Should text labels also be supported?
[/quote]

  • i certainly ‘feel’ like it should though
  • certainly in a limited way and it should
  • be able to distinuish at least two types of slices: …

Re: [quote=“odevices, post:16, topic:246”]
Should algo-inserted slices be treated differently from user-inserted slices?
[/quote]

  • i’m not sure how the difference between algo-inserted and user-inserted would
    make a difference to me right now, i’ll have to think about that more…
  • but i feel strong about the possibility of storing slice-sets and applying them to the same file or another one combined with adding and deleting slices to/from a given slice-set then store again etc. for all the corresponding use cases i would probably need to be able to distinguish between already stored and applied slice sets and additionally “user-inserted” slices.
    (- with the support of textlabels different solutions are possible. e.g. “P.xyz” for patternized slice-sets and
    "A.xyz" for additional slices)
  • i’d like to see algorithms, too. lots of them!

Re:[quote=“odevices, post:16, topic:246”]
How do I present the association of multiple slice sets for one audio file to the user?
[/quote]

Re: presentation in the list of slices
(- by the way, everytime i open the list of slices in the slicing interface i wonder why that list
won’t appear on the sub display…)

  • we already have access to a list of all slices when we’re in the slicing interface.
  • and we’re already used to the fine art of digging deeper into a folder hierarchy by
    going from left to right
  • and if the initial list of slices can make a difference between slice-sets and simple slices
    then i could enter the slice set by, let’s say clicking the enter button: the choice to see either only the
    slices of a chosen set or all fo them in correlation would be nice.

Re: wave-form
(which seems to be the harder part, and unfortunately i am not in front of the beauty, or was it the beast?)
(- most of us are used to have a regular grid in the background or on top of a graphical presentation
of wave files. it would be useful for sure but combined with different types of slices that could make
the GUI pretty dense, depending on…so many things:)

  • if we would have to tell only two types of slices apart a division in an upper and lower part would
    suffice. e.g. patternized slice-sets would populate the lower part and additional slices could then be read on the upper part.
  • am i right by thinking that the only use case where a continuous line is absolutely needed would be
    for the cursor and the representation of a particular slice or set of slices (chosen from the list) since we desperately need
    a continuous one when we take custom made zero crossings seriously and/or deliberate deviations from them…?

Re: [quote=“odevices, post:16, topic:246”]
How do we author and manage meta-data for audio?
[/quote]

  • this meta question keeps popping up all over the place and i am not aware of
    a particular thread that would collect all relevant considerations in one place…
    one of the places where such a thread was discussed was the 301 file organization thread
  • since that thread i am stuck with a pretty blurred idea of ‘audio objects’
  • but i am almost sure that a clearer concept of such a ‘thing’ could yield some insights concerning
    our storyboards of slicing and the storyboards of other cruel things that you can do to audio.
    (i.e. cutting, cropping, muting, distorting, folding, reversing, mutating, muting, droneing, drowning,
    echoing, reverberating, vibrating, …)
    welcome to the little shop of audio-horrors!

@odevices: but seriously: what do you think is wrong with how we author and manage meta data
for audio at the current state of affairs?

what do you think


#19

I had the inspiration to build a repository of 12TET instruments from my ZynAddSubFx soft-synth that I would really love to use with the ER-301. After exporting a bunch of single stereo sample files with an as big as possible octave range, and loading them into a sample player, I realized this job is way to tedious without a threshold/zero crossing sort of auto-slicing feature, so I would like to revive this thread (hoping that this is the right place to ask about it). So, I would like to ask in all humility and with buckets of respect for @odevices general planning, what’s the status of this feature, position on the priority list, and interest of my fellow users? Is it somehow implemented and I’m missing something…?

Alternatively, I’m curious to know if there is a different way of building this repository. I might be unaware of other features that have been implemented since this discussion, that could take care of this kind of job in a different way.


#20

There is a ‘slice by onset’ feature, even though there are some differences – Brian described it’s a bit different from threshold slicing, but has worked pretty well for me regardless.