Elektron-Users

darenager wrote:
To be honest my intention was for it always to be constructive, that is after all the point of this forum, and I'm not too egotistical to not take stuff in and even admit I'm wrong or that I misunderstood something if that was the case.

Yes I think a lot of what is being said is of the same sentiment, but unfortunately sometimes our different experiences can lead to different ways of saying and doing things and possibly a bit of confusion and misunderstanding.

Back on topic:

I have a very good feeling that a lot of what is being wished will come in future updates, a very long time ago I asked for samples slots to be p-lockable, sample locks are almost there but a few small additions such as having slot available as an LFO target could prove to be very interesting too.

Sample chains are of course very handy, but the trade off is some preparation is required, it would be nice to have a machine to faciltate their creation - we can do it manually right on the OT by using sample locks and resampling, then manually slicing and saving as a new sample, but it sure would be great if the machine would do this automatically, then assign a special chain playback machine that has a parameter in place of slice which shows the names of the sample in each slice - possibly on the same area of screen used to display sample locks. The difference between this and actual sample locks is that only 1 sample slot (albeit a longer one) is required and therefore slot assignment becomes much more efficient and simple, and a few chains themselves could also be sample locked giving a much greater choice of possible sounds on a step. This chain machine could double as a kind of granular machine if very short slices were used, with perhaps some small modification to the envelope to control any pops etc.

I didn't doubt at any moment about your intentions of being constructive.
I just doubted about the solidness of your arguments regarding parts.
Please also note that my language isn't native English. So, many thoughts of mine can come out a bit distorted and maybe sometime offensive for someone. If this has happened I would like to apologize.
Sample chains as I have already expressed have their strong points. Somone can easily fit a whole track inside one sample slot. If only there was a merge option of the sample buffers or an audio editor function that could join sample files then sample chaing would become priceless.
The handling of sample chains is a bit tricky but very rewarding. And with the os updates i think it will become unbeatable.
Your thoughts about the granular machine are very nice but I think should come in at a later state of updates along with all the requests about loopers and new stuff. However loopers is a feature that has been promised and a lot of people might be waiting for it.
The things that should be prioritized now are the issues of optimizing existing features. Like the parts that have been the great issue of this thread.

Fair points, and certainly no hard feelings here

A sucessful thread is about the sharing of experiences, knowledge and opinions, I think this has been the case here, your 'determination' and arguments certainly made me re-look at some of these points raised and from a different perspective, so a big thanks for that

I wish the OT´s file management system would be simpler...

in example, my ESX is dead simple and functional...you got 1 sample pool and 256 patterns per "session"...you just select a part, browse the sample and that´s all...

saving the pattern just save the associated samples with it, so when you dial the pattern it just plays the samples...easy...

I wish the OT´s file management system would be simpler...

One way I like to work without having the fear of destroying any other PARTs is to have an IDEA in each of the BANKs. By selecting an empty BANK, I can start something new without having the danger of destroying previous PARTs .

If then I want to work on one of the ideas, I would go to that BANK and start making few patterns for each of the 4 PARTs.

Also when I am building a tune in a BANK, I would limit myself to use PART1 for the first 4 patterns, PART 2 for the second 4 patterns and so on...Of course I would be copying and pasting parts in between and make alterations to them

Not sure if this was covered here but thought I would chip in

dataline wrote:




One way I like to work without having the fear of destroying any other PARTs is to have an IDEA in each of the BANKs. By selecting an empty BANK, I can start something new without having the danger of destroying previous PARTs .

If then I want to work on one of the ideas, I would go to that BANK and start making few patterns for each of the 4 PARTs.

Also when I am building a tune in a BANK, I would limit myself to use PART1 for the first 4 patterns, PART 2 for the second 4 patterns and so on...Of course I would be copying and pasting parts in between and make alterations to them

Not sure if this was covered here but thought I would chip in

^^ this is what i do... pretty much.

anselmi wrote:
I wish the OT´s file management system would be simpler...

in example, my ESX is dead simple and functional...you got 1 sample pool and 256 patterns per "session"...you just select a part, browse the sample and that´s all...

saving the pattern just save the associated samples with it, so when you dial the pattern it just plays the samples...easy...

I wish the OT´s file management system would be simpler...
^ This! And it even does "sample chaining" and slicing by Transients (which I used to hold more drum kits). Now I don't miss my ESX's sound, but I do miss its simplicity. Anyway, OT is a different beast altogether, and I don't think it will ever be as simple to use as a Tribe, so we better get used to the way it works.

darenager wrote:

Sample chains are of course very handy, but the trade off is some preparation is required, it would be nice to have a machine to faciltate their creation - we can do it manually right on the OT by using sample locks and resampling, then manually slicing and saving as a new sample, but it sure would be great if the machine would do this automatically, then assign a special chain playback machine that has a parameter in place of slice which shows the names of the sample in each slice - possibly on the same area of screen used to display sample locks. The difference between this and actual sample locks is that only 1 sample slot (albeit a longer one) is required and therefore slot assignment becomes much more efficient and simple, and a few chains themselves could also be sample locked giving a much greater choice of possible sounds on a step. This chain machine could double as a kind of granular machine if very short slices were used, with perhaps some small modification to the envelope to control any pops etc.

This is kind of what I was hoping for, a sort of kit machine.
Imagine having a folder that is turned into a (drum?) machine, each sample inside the folder is comparable to a slice, only it has a name. Maybe the folders would have to be limited to a certain size (MB and/or number if files) to work with available RAM... Even if it could only be 16x1 second samples, this could be very nice.
Before using sample chains I thought about this a lot. Sample chains are helpful, but still not perfectly ideal for drum programming; they're more of a workaround.

Indeed, and if the samples are mono I think quite a few sounds could reside in a few chains, things like kicks, snares, and percussion are often less than 1 second in duration so it would be quite handy to have a longish (32 or 64) slice chain for those type of sound, then say another chain for cymbals, hats and longer sounds.

Going back to parts for a second the midi tracks are also subject to part settings, it would be good if you could have the option to have midi tracks ignore part settings, maybe in an option setting.

darenager wrote:


Going back to parts for a second the midi tracks are also subject to part settings, it would be good if you could have the option to have midi tracks ignore part settings, maybe in an option setting.

This could get confusing, though I don't know that I have a better option to offer.
User customization options are nice, but there's something to be said for machine-wide uniformity. I just think of MIDI tracks as another machine type, with parts, albeit no audio effects. And I imagine there could be instances where you may want to have different midi setups (defined by parts) with different patterns/songs/however you want to think of them. I guess what is there works for me, and I'm getting more comfortable with it every day.

The idea being that the setup information is stored per project, because I agree that sometimes it is useful, so by making it project specific nothing is lost. Or another idea could be that internal tracks and midi track part settimgs could be copied and pasted independent from eachother, so if you have spent a while doing your midi config and building a sample/machine assignment in part 1, and in part 2 you just want the midi the same, you just copy the midi part only.