anyone used beatlookup & lucifer to compare?

[JuanSOLO]

Long ago I tried the multiple samplers, but my main tool is Ableton Live, so Live kind of takes care of the multiple sampler aspect.
I have often contemplated a stand alone Reaktor rig, but there is always something about Live that brings me back to it, not to mention I have never dedicated myself to completely earning to build in Reaktor.

I use effects like BeatLookUp on a Return Track in Ableton. I have 1 Return Track with various mash up effects on it. I also have a 'Clean Return.' All of my tracks in Ableton can toggle between clean or mash returns through using sends, with the output of each track set to 'sends only.' This allows me to send anything I want to something like BLU with a controller such as the APC40 with some custom mapping etc.
I also have a dedicated Midi Track in Ableton routed to the MASH FX return which takes incoming midi notes from whatever controller and triggers BLU. This also allows me to use a DrumRack in Ableton with blank instrumentRacks that are named as such, Jump 1, Jump 2, Jump 3 and so on. So when I am editing the piano roll in Ableton I can see what notes are triggering what due to the naming convention of racks reflected in the piano roll..

Personally I like the idea of BLU having 16 Jump positions in a 2 Bar Loop fashion each of these positions triggered by incoming notes. Then simply a knob that adjusts the duration of the slice i.e. Whole note, 1/2, 1/4, 1/8, 1/16, 1/32, 1/64. I never have a set duration I favor.
Maybe an adjustable loop size, where you can tell BLU wether or not the incoming loop should be chopped by 16 in 1, 2, 4, 8, or even 16 bars.

This seems to fall in line with Maschine users too, where 16 pads could trigger 16 slices old school MPC style, with a twist.

One thing I didnt mention before, but the way Sends are routable from BeatLookUp to Live are really COOL. A feature that seems overlooked yet makes BLU amazingly fun.
Maybe each slice position could have a SendA and SendB toggle. So if you wanted your snare slice to send to a reverb or a delay that would be possible.

where the location of the hit points was based on the incoming loop,

please elaborate on this one. sounds interesting indeed.

SO, what have you been up to Chris? Building synthesizers again?

[JuanSOLO]

Come to think of it, I am not sure what is more user friendly
16 notes that select 16 different positions
OR 16 notes that select various lengths/durations

With this mod I did a while back, the buttons select a different length and the knob chooses the position.

[CList]

where the location of the hit points was based on the incoming loop,

please elaborate on this one. sounds interesting indeed.

SO, what have you been up to Chris? Building synthesizers again?

You may know Beat Slicer (by James Walker-Hall, in the standard library), it detects hit-points in the audio in the same way that a lot of samplers do; like Acid, etc, where the high-frequency transients in the audio are used to create "hit points" which act as the starting-points & lengths for the sample-slices that are extracted from the loop.

BeatSlicer uses a "press here to analyse the sample loaded in memory" system to get the hit-points. I used the "code" but tweaked it around so that it could process incoming samples in pseudo real time and get the hit-points as soon as it "heard" the sample. It then stores these in an event-table. So basically if you set the sensitivity to high, you'd only get maybe 4 start-points, based on the 4 loudest transients in the sample. If you set the sensitivity lower, you get more start points. If the hit-point event table were used as the position/length of your BLU jump points it provides some interesting options. The only problem (or perhaps the benefit!) is that you're now basing it off of the sound and not the beat, so if, e.g. the snare on the 2 was a little late, then your jump point wouldn't be to beat 2, it would be to beat 2 + 20ms, but that point would be right on the start of the snare drum sound... the problem is that if you let it play out the rest of the loop from there it would sound a little late... I dunno, just brain storming...

As for personal life; I've been working a lot, I got married (wife says I spend too much time at the computer and not enough with her, so yeah... not as much reaktor...), playing a lot of golf, renovated a couple of apartments, (which led me to dabbling with carpentry/cabinet making a bit), etc... No shortage of activity that's for sure!

Cheers,
C

[JuanSOLO]

Yeah I recently got married my wife says the same, and she's right, I know this. Now back to computing.

So I am vaguely familiar with the BeatSlicer. I imagine it's more because the analyse sample part.
HOWEVER, this idea sounds really awesome especially if it's in real time.

The thing is with something like Jump points and having 16 selections, I really only find myself using 2, maaaybe 3. The kick on the 1, a snare, and maybe some other spot.
So I feel like this 'hit-points' detection with sensitivity adjustment could be really valuable.

As I had mentioned earlier, I'm not sure which is more valuable/useable when "playing." I am starting to think as in my picture, the extra buttons are better for durations, more fun, more useable.

So maybe the hit-points detection could be set up where you could set the amount of hit points to detect.
For example, lets say you have and 8x8 matrix of buttons/notes.
Adjust the hit detection between 1-8 (represented on the matrix horizontally, position in time)
Vertically the Matrix would be duration of the detection.

So if you set the hit detection to 1, it will always be on the 1. (or maybe this is assignable, isolated from detection)
Yet if you raised it above 1 up to 8, pending on sensitivity, the hit detection would grab the 7 most dominant peaks and spread them across the matrix horizontally.

So if you chose 2 for 'hit detection' you would definately get the hit on the one for sure, and the second hit may or may not be the snare. Either way this could be fun, somewhat random, somewhat organic.

So if a user had something like a Launchpad, they could choose how many columns they wanted to sacrafice to the hit-detection, this might be 1, this might be 8.
Same for and APC40 or so, yet instead of 8 lenghts you would have to choose 5, seeing that the matrix is a 8x5 grid.

HOWEVER, I feel like at least one of these slices should be independently assignable or isolated from the hit-detector. So you could at least KNOW for sure that your 1 column in the matrix would do exactly as you expected/assigned it to position wise.

make since? I could whip up a quick graphic representation at work tomorrow if needed.

[JuanSOLO]

what if the detection could also be prone to respond to frequency values. hmmmm

[mike_o]

I just wanted to post up in here and let you guys know that you should check out salamander anagrams work here...

http://salamanderanagram.wordpress.com/

this guys been building some really solid ensembles the last few months and his programming is top notch.

[mike_o]

I've got a question for you Chris, I'm playing around with oki computer right now and extracting just the oscillator components, which I've done without any issues.

the problem comes in where I am trying to put a switch on the oscillator so that it can be turned on or off. its for an ensemble with selectable oscillator types.

after turning the oscillator off and then on again all the waves are deactivated, you must re-initialize all 16 slots manually.

I am trying to figure out a way to make the oscillator system auto initialize upon re-activation but I have hit a serious brick wall.

any chance you could help with this?

I know you didn't create oki computer but it seems as though your programming chops on up on the same level as this thing and there is almost no way I'm going to figure this out on my own.

if you can or if you cant, thanks either way for your work.

mike_o

[CList]

Actually I'm a big fan of the sound of Oki Computer and did several different variations of it myself back int he R4 days.

Here's my first thoughts:
1. Using a switch and creating those global-reset events can be a drag. The easiest fix is to just get rid of switches altogether. If you want the switch because you want to save CPU, this can now be done with some programming in core using core-based oscillators. The osc. itself will be slightly higher CPU than the primary one, but you can de-activate it without using a switch by simply putting a gate type of structure on the sample-rate clock signal and controlling that gate with a "on/off" event port sent into the core cell. You can also create a core cell that switches between various types of oscillators this way and turns the unused ones off, again w/o creating a switch. I can elaborate if you think this will work for you.

On the other hand, if you need/want to have switches - or if there's already a lot of switches int he structure, then the global events will be a fact of life and you need to figure out how to deal with them. In this case, I'd need to look at your structure. Very often you can create a sort of initializer -> ForLoop kind of a structure to do your re-initializations. You can simply put a constant module with a value of "1" as the trigger to any for-loop, and it will fire the loop on any global-reset (dig around my BLU for "For-Loop" macros, I almost always use those in place of regular Iterators because I think they are more intuitive and cover 99% of the use-cases).

If that concept is already what you're doing and/or you need more help, let know and send post a file somewhere for me and I'll take a look.

Cheers,
C

[CList]

BTW, I've had some of my Oki files up on my website for years, though only the last one will open in R5+ (the rest are R3 files).
Check this one out if you like:
http://www.semaforte.com/reaktor/files/ ... ndai04.zip

It includes some new wavetables that I imported from the Waldorf Microwave (I used to own one of those) as well as my arpeggiator.

**IMPORTANT** it will open to the "B" view (because it's an old R4 file). Change it to "A" view when you start the Ensemble or it will look all screwy!

Cheers,
Chris

[mike_o]

Thanks for the reply but I should have been more specific, it was oki computer 2.1 that I was taking the oscillator from, totally different type of oscillator engine.

about 10 min after I posted that question I figured out what to do to make it work, it took several switches to turn everything off and then on again but I got it working, I am very interested in your core work around for the switches though.

the ensemble I've built is a huge multi synth with 4 oscillators and 7 selectable oscillator types so I had to use switches to keep the cpu load in check.

right now the switches are only having a negative affect on the stereo field, whenever a switch gets pressed it centers the sound a bit and narrows the stereo field, not all the way but its noticeable, aside from that their not really affecting anything.

I am only semi literate in core so if you have one of these switches already built I would love to look at it.

Thanks again,

mike_o

[salamanderanagram]

mike, a core switch is basically made by routing a clock into a macro if it's on, and not doing so if it's off. then it takes a bit of careful programming to make sure that the macro does nothing when it is not receiving a clock (IE don't use S.R.C, replace them with a clock of your own making, use latches on audio inputs).

this is how optimus prime works. the guy who first posted it on the reaktor forums was named jay_dizzle but i don't remember the thread name, it was before my time. there is a simple example and explanation on that thread though.

[CList]

Here's a super-simple example of how it works.
http://www.semaforte.com/reaktor/files/ ... tching.ens

The core cell contains 3 osc: the original one (not connected) and two modified ones, where I disconnected the SR clock from the guts of the structure and replaced it with a new connection running from that "Phase 2" macro (where the SR.C gets used to do work) all the way out to a port on the macro.

Next I created a sort of routing system with a pair of compares for the SR.C (which I put at the top level of my structure). If the Ctl value (parameter from outside the cell) is less than .5, then the whole thing is off, and the sample rate clock simply latches a value of 0 to the output (a latch like that uses basically 0 CPU, and this makes it so that the osc output doesn't get "stuck" at whatever the last value was when it was turned off. If the value is between .5 and 1.5, then osc1 gets the clock and runs, and if it's > 1.5 then osc. 2 runs.

You can watch the CPU usage and see it change as you change the list to pick the oscillator, but this is not happening via switch, it's happening via routing in core. In primary all audio-type modules that are active are always running and always using CPU, but in Core, only the audio modules that are receiving audio-rate "events" actually use CPU (I put event in quotes because in core, audio and events signals both work the same way, but in primary they do not, so I don't want to confuse things).

[mike_o]

Thank you both very much, I'm going to do some experimenting and see if I can get the hang of this.

I just happen to have today wide open so I'll post back after I get a chance to try some of these things out.

Thanks again.

mike_o

[delicioso]

Lately I've been thinking about getting back into it just for the hell of it, and 'cause I miss it...

So the point of my post here is that if anyone using Beatlookup has any features they'd like to see added, any suggestions for variations-type instruments, or bug announcements, I'd be happy to hear about 'em.

A TouchOSC or Lemur template would be amazing. Or at least make the event table sequencer in Beatlookup 5.2's Loop Ripper to be MIDI mappable so we can make our own TouchOSC template for it.

[mike_o]

I'm coming along a little slowly on this whole switch thing and I just wanted to check a few details.

I understand how the switch works for turning things off and on inside of core, but can this method turn things off and on outside of core?

here is an example.

I've got an LFO going into oscillator pitch, it runs through a switch on its way there so that I can turn the entire LFO macro on and off as needed to conserve cpu.

can this switch method replace that so that it can activate and deactivate external macros outside of the core structure? or does this switch method only activate and deactivate things inside of core cells?

right now I am doing tests with standard envelope and LFO macros being routed through a core cell. The LFO/Env stay active at all times no matter what I do, even when the internal structure of the core cell is completely disconnected.