Exile-ish Ensemble Project

...continuation of the thread started by Rachmiel in the regular Reaktor forum, this thread is intended to focus on the actual building of the instrument, including feature requests, request by me help, bug reports, suggestions for improvements, and technical questions. Consider it a sort "phase 2" moving beyond the "does anyone want to work on this phase.

Here's the original thread:
http://www.nativeinstruments.de/forum_us/showthread.php?t=30713


I'll start with the Revision Histroy so far...

 

From 2005.12.05
Well I've made some more progress. After sitting back and doing some thinking on the whole grain concept I came up with a way of "doing the granular thing" that is - I'm pretty sure - the best so far in terms of both versatility and CPU efficiency. A detailed explanation would take too long, suffice to say that it's pretty slick, IMO, as it uses only one extra ramp to calculate the play position of both grains and the amplitude envelopes. Vectory does some math with the two grains that, for all I know, is very similar to my method, but I don't understand it and didn't spend any time figuring it out, so I'm not sure. I do know that rather than x-fading the two grains as Vectory does (which implies a fixed grain-density of 1.25) mine generates two separate grain amplitude envelopes which allows for grain density to vary (up to a max of 2), and I believe that mine is also more CPU efficient since the math is done in core and no cross-fade module is used (the two amplitude envelopes are computed by simply doing math to transform the grain positon envelope).

I also started cleaning up the keyboard control section. use keys 2,3,5,6 to switch the "target" of the keyboard commands. It's getting very clear to me, however, that there are not enough keyboard keys for any sort of really fancy control. Is it just me, or does everyone not have the ability to drop the keyboard down 2 octaves with ctrl+shift?

Anyway, check it out...

- CList

 

From 2005.12.05 - that night

Revision 3

The file is now over the 100kB limit for uploads, so you can find it here:
http://www.semaforte.com/reaktor/files/BeatLookup.3.zip

To save space I've set the AudioTable's "Save data" parameter to 0. When you open the file, you MUST set the size of the audio table in the audio table properties to x=250000 y=4, and then set the Min/Max range to -1...+1 !!!!! ...you can then, if you like, set the "Backup data with module" parameter int he audio table to "on" and save the audio table. The size of your file will increase by about 4MB. (note that the AudioTable I'm referring to is in "Loop6", you can right-click and go to properties from the panel).

Features Added:
1. Buzz effect with a randomizer. Having deleted the Exile ensemble from my machine to not be tempted to use it for ideas, I'm not 100% sure how his works. It seemed to jump around every once in a while, so I added a randomizer. It definitely had a "portamento" on it, so I added that at the core layer.

2. TimeStretch / Tempo shift effect. This one is not in the Exile ensemble and is only possible with a truly grainular sample player. I think it sounds great - especially when used in conjunction with the other effects.

3. Input Recorder
Currently audio table based, but if you look in the structure you'll see I have the guts of a core table version that I'll probably use in a later revision to record in stereo and save some CPU. You "Arm" the recorder and on the next downbeat it will start recording for one loop - based on the number of beats set with the knob. You have 4 record buffers and you can record to a different buffer from the one that's playing or the same buffer. It's currently tied to the soundcard input, though I plan on making it switchable to record the audio output, or maybe some other things. I'm also thinking of making it so that the number of beats is saved with the buffer - so different buffers can be different lengths.

Fixes/Changes:
1. Made the stutter effect 100% event driven - it's no longer driven by it's own ramp at the core level. I did this just to show even more how a knowledge of core is really not that essential for doing things like stuttered playback of a ramp-based sample player. I don't know if this actually saves any CPU, but it might save a tiny fraction. Students may want to compare/contrast the way the stutter works against the way the Jump-To-Beat works. I'm thinking of making Jump-To-Beat work the same way and drive it from an event clock in the "KeyControl" macro.

2. Several little bug fixes.


Going Forward:
1. How's the CPU holding up for everyone? That granular playback is a bit expensive, I'm up to 7% CPU on both my desktop and laptop, and there's still no effects in place yet. What do you think about the current CPU usage? I suspect effects and possibly a little micro-synth are the only CPU-hungry items left to add, and those will be monophonic.

2. What other features do you want? How would you like to see them implemented? The "DJ mode" would be easy to add, and I've thought of ways of putting it in that might be a little more versatile than the one in the original. What about QWERTY keys to select samples? Making concatenated multi-samples for use int he Sample lookup modules is a bit of a drag, so I haven;t added this yet, but it's very easy to implement.

3. What do you think about the current way the recorder-box works? Do you want it to work differently? Do you think it'd work in a live env.? How should it be changed / enhanced? How important is it for the recorder to do stereo?

Please give me more suggestions for things you'd like to see - this was supposed to be a group effort! This thread has gotten so long and gone on so many tangents, that maybe we should start a new one. I wonder if a lot of people have stopped paying attention.

- CList

 

Revision 4
The link:
http://www.semaforte.com/reaktor/files/BeatLookup.4.wireless.zip

Check previous post regarding setup for the audio table!

The revision has a lot of changes...

1. The most notable is that you can now toggle "keyboard contol" (or "cut-up mode", or "edit mode") for each looper independently. When you see a big red light above the loop, it means it's in edit-mode, and your keyboard commands will affect it.

2. Rebuilt the core layer, standardized a lot of functions and added a lot of comments. Made it automatically drop out of granular mode if there's no reason for grains (i.e not pitch or tempo shifts).

3. Added grain / non grain option.

4. Added mutes, I'm not too sure if I like the way they work right now, but give 'em a try. You can mute unmute by hitting "S" when the looper is in edit mode (to mute/unmute multiple tracks), or by using [shift + loop edit key].

5. Added the loop and 1-shot modes to the global stutter/gate sequence

6. Added automatic detection of number of beats per loop!! This is based on (see item #7)

7. Added "loops per sample" knob for multi-samples that are concatenated together. You can select the sample to play with (see item #8)

8. Added sample-select with QWERTYUI keys. Current sample will only change when the looper is in edit-mode. All loopers that are in edit mode when you press the key will change sample.

9. Changed colors to a holiday theme (not intentional, it just ended up that way!)

10. Replaced a lot of wires with wireless send/receives. This may turn out to be a bad idea in the long run, but it makes working on it a lot easier. Let me know if it causes any problems for you , only problem I can think of is that they'd show up as automatable items in a VST host.

11. More sexy progress bar with beats and downbeats shown (currently only in the first looper "#2")

12. Moved all the midi on/off controls out of the "keyControl" macro and into the individual loopers.

Note that looper #2 (the first one, that you control by pressing "2") has some things that the others don't, and is the looper that is most "finished". I would have copied it out to the others, but I was lazy. If anything is working in Looper #2 and not in the others, it's just because I haven't copied it out yet.

I really want to start digging deeper into, and cleaning up, the audio-recorder, but haven't had the time yet. Also starting to think the "scratch mode" would be nice, and would sort of take over for the "S" key mute function since "stopping the record" is basically the same as mute for as long as you've got the record "held". Again, it's becoming more apparent the more I use this how Tim's work brought him to the instrument he made.


Cheers,
CList

 

Same here - doesn't work in R5....
I also would like to be able to use all the key on the computer - not only the faked semi note keys.... as it make more sens in this kind of ensembles.

 

yes! i love abletons method of MIDI learn being seperate from computer keyboard learn. ableton also has a keyboard as a midi keyboard feature, but if a comp keyboard is used for, say, triggering a clip via keyboard learn, then that key doesnt work in the fake MIDI keyboard thing.

as ive said, a keycommand module would be cool. just dont allow any standard reaktor keycommands to be used in it (like ctrl +c/v/x or s, for example), but being able to use it instead of the standard fake MIDI-keyboard for an instrument would be cool. it could work like the mouse-area, except there would be a seperate output for each keycommand, which are themselves chosen in the proerties, it would be like setting up the list or multitext modules.

 

No offense guys, but please try and keep this thread for just developement options for the instrument whenever possible.

Note to those who've downloaded R4
The CPU usage will be high until you load it with samples. I suspect this is due to the divide-by-zero operations that happen when no samples are loaded. It's no big deal (since the CPU usage goes way down when samples are loaded) but I intent to fix it in the next release.

Cheers,
C

 

just tried beatlookup out for the first time. very fun!

a suggestion (if it's already been discussed, my apologies):

what about random options for the jump and tempo buttons? either/both could be quantized ... or not.

one more:

possible to make the samplers have independent button sets? so that one could manipulate them separately/polyphonically?

groovey.

rick

 

To quote herr Nowak: ^_^

Damn, I forgot about that - see, that's why we need you here on this! It's coming up. I'm thinking random jumps will happen on Shft+X and Shift+C. Jump-tos will either be quantized to the action-quantize or the loop length of the jump-to chosen for randomizing (which would kind of make more sense as it make the keys do different things). What do you think?

That's very tough since we're already using up all the buttons. Note that when you get comfortable / skilled, you could theoretically do this by being fast with the various "edit" keys and switching back and forth. Also, since it now "gates" the key action with the edit keys (unlike the way it used to work back in R3), you could do a jump-to loop on one sampler, turn editing off and it will stay "stuck" on that mini-loop until you go back to that sample and tell it to stop. I think that's the best I can do given the limited resourse of the laptop keyboard.

One thing I could do to give us more keys is make it so that there's simply "current sample up and down" rather than dedicated keys to switch to each of (possibly) 8 samples in a loop. Thoughts?

I'm in the middle of a complete ground-up rebuild of the recording looper using all core "arrays" for a massive (yet simple) 16 buffers (8 samples x 2 stereo channels) of 20 seconds each. It's rad and very low CPU (lower than the Sample-Lookup), and it will also have a non-core section using an event-table to display the samples recorded to the buffers!

- CList

 

Please excuse the saliva on my keyboard.

Even using various smoother techniques, I've never been able to completely rid audio table recordings of clicks. Here's hoping you find a better way. Cheers.

 

The big rule for click-free audio table (or array) recording - which you may know - is that you absolutely must use an integer counter for the write-ramp. You cannot use the "ramp" oscilallator since it will always output float values. For playback, it's a good idea to use at least linear interpolation for fractional sample index values.

The recorder is getting complicated. I want it to store the length recorded with each buffer, as well as the tempo at the time the recording was made, and then recall them when the buffer is selected. All that could take a while, but the initial 8-buffer recorder / player with event-table display is ready soon as a sort "proof osf concept". Note that the event table for display is not the best, it looks a little "choppy", but it at least gives you an idea of what the audio looks like, even if it's not perfect.

Here you go. *only the first buffer is connected* (as you see if you drill down a little into the core cell). That's because I figured; "why wire up 8 buffers when I'm not done with the first one that I'll be using as a model for the others?".

This file also includes a very minor change to the Ramp core cell that gives slight CPU boost and reduces chances for clicks after looping (I don't know why I thought I had to do an integer modulo on the output, it just needs to be wrapped). Also includes the beginnings of a turntable-scratch mode, activated with the D key (no scratching yet, just "stop", and it's not in place on the recordable looper, just because that one requires more work to change the core cell since it's not just a cut and paste).

the link: Version4.2
http://www.semaforte.com/reaktor/files/BeatLookup-v4.2.zip

- CList

 

a cool idea maybe - have DJ Mixer-styled "kill" switches, for killing frequency ranges. maybe 3 bands each, with crossover frequencies. im sure this can be done CPU efficient if the right filter types are used, but damned if i know what to do! i dont think this is on the Exile original, but it would definatlely be sweet, as there are plenty of nice playback effects already, this would help with mixability.

anyone who is using this with who has some ssort of faderbox, most definately MIDI learn some controls. on my radium, my faves are volume controls with the faders, and grainsize/grainpitch on the knobs for each channel. controlling the playback FX is more fun on the keys as well, although the current keys used for changing the "active" FX tracks dont fit in the octave range as the rest of the FX, but that shouldnt be hard to fix.

only thing im noticing any probs with is the buzz effect. since it depends on the current position in the waveform, the effect ranges from inaudable (especially on sparse rhythm loops) to INCREDIBLY LOUD (as in, louder than the loop is normally playing back, it seems). maybe some sort of "latching" until the next transient peak (or suitable volume requirement) is recieved will help the quietness problem, but it might be too much and really i guess its more about practice with performance stuff like this (plus the acion quantize may help if on a course setting with very "on-the-beat" beats).

for the most part, though, this is coming out VERY NICE! =)

EDIT - OK, another "doh!" on my part, the FX arm buttons are on the middle-most black keys in the "useful" octave. even better! guess i should pay better attention to the computer-to-MIDI keyboard mappings.

 

some more suggestions: i think the exile ensemble has each channel containing both sampler and live samplers in each channel.. not sure if this would be better, but having a fourth "normal" sampler would be nice.

also, resampling would be great, im sure you are thinking of that soon though (especially great is resampling a loop while doing playback FX, i think that is what tim is doing in the video when someone said it looks like he is "recording" key tweaks).

finally, i think having the grain density at a low value gives a better "gate" effect than the current envelope one, plus the current gate effect seems to be the weakest so far and the only one that doesnt always work 100%. maybe because of the event-based hold envelope, in the manual it says that it uses the control clock. that is just a personal choice, though, and i have to say the table for the stutter effect is just plain sweet.

i know i should be trying these tweaks out myself, but i figure they are all valid points worth posting.

 

OK, nice to get feedback, let me cover some thingsas I ssee them unfolding here, and you can comment...

I like the idea. I noticed from the Exile screen shot that he has HP and LP send effect switches which might be a similar thing. Effects are still a "to be done" item.

Yeah, absolutely, that is certainly the idea here. I'm surprised you didn't say the Beat-jump position, and the buzz length because to me those are the most usable fader controls to be moved *while you are hitting keyboard buttons*

See note above for changing buzz on the fly w/ midi faders while turning buzz on and off. Also, I've gotten into the habit of only hitting the buzz key while one of the "jump-to" keys is held down, then I have a much better sense of what it will sound like.

- CList

 

I agree about the gate effect, perhaps making it sound more like Vierring (i.e. "glitchy") by making it just an AD envelope with variable delay time would be the hot ticket here - still not sure though. Not that having gate and stutter tied to the same clock migh be the problem as gates tend to sound better at ower speeds and stutters sound good at lots of speeds.

Thoughts?
Keep in mind that there's lots of trade offs going here and the idea is keep the UI simple!

Also... I was out having a beer (or 5) at my local tonight, and came up with something that might be brilliant for the "scratch mode" - or it might fail miserably, we'll see. I'm saving it for a surprise. Should have it done by Sunday.

- CList

 

yes, the buzz length actually was my first midilearn, to the modwheel. i thought of midicontrol for the beat jump controls to my last 4 available faders after posting the first time - having the position AND beat jump lengths midi-controlled is great for switching between stutters and drum-roll effects in a second's time.

 

about the scratchmode - sounds nice. i think that was the hardest part to "get" in the exile demo, but i guess its not exactly simple in traktor either (or a real turntable, god forbid!).

 

Yeah, the problems I've had have been the result of starting or stopping the recording when the amplitude of the input is not zero, thus resulting in clicks upon playback. The easy way, which theoretically should work, is to smooth from 0=not recording to 1=recording, multiplying the output of the smoother by the input audio signal. However, this was never reliable in my attempts. Perhaps you're core smoother is better at this. (Ableton Live has a snap-to-zero feature, which moves a sample's start- and end-points to the nearest zero-amplitude points.)

I haven't yet looked at your core code for this. Are you attempting to store this info in the same buffer as the audio?

Thanks again for all your work.

 

Have you experimented with cubic interpolation, especially for like when reading through the buffer at a less-than-medium pace?

 

I personally don't think it's worth the extra CPU - which is more than 3x linear. It's a small amount , but when you factor it over a couple of loopers, it gets to be significant, and the difference in sound is pretty marginal from what I've heard (difference between "good" and "excellent"), especially considering the fact that (at least in this application), if you're not playing at regular speed, then you're applying some effect. If you feel like putting a cubic interpolator in there and trying it out the place to do it should be obvious (email me if not), I'd be curious to hear the results if the difference is significant. I'm too lazy to try it

- CList