West (Reaktor) programmer

[Joe Soap]

Yup, got it - cheers fella.

[Phil999]

great stuff Macciza + AB. These LED's are brilliant. Magic.

What I still wonder, what have you exactly changed in the Ensemble? From where do you send OSC to Lemur?

What I also struggle with is with beginning and ending strokes. For example, how to make the knob ring (grey outer ring) darker, and the indicator line brighter? I can only change both colours at the same time. Tried to insert colour (style) commands at different places in the script. But I guess it has to do with beginning and ending strokes.

[Macciza]

No worries mate

In the Ens it was a matter of finding the various LEDs and what was driving them and inserting an OSC sender, or an audio to Event converter and then an OSC sender for some that used audio signals. Some are at top level, others further down.. Then it was a case of working out the colour logic being used by checking the ensembles workings . . .

Yeah sorry about that, bit of a quick hack, not commented or optimised at all, will look at tidying it up a bit, some of the elements aren't laid out the best, could be split a bit more to enable easier edits, will have a look and send something back.

Cheers

[Macciza]

Phil,
Further to discussion of canvas_save/restore functions . . .
They are implemented as a 'Stack' - pushing and popping data in and out ...
So what does that mean?
canvas_save(c) // State 1
...... Translate scale etc . . .
canvas_save(c). //State 2
...... Translate scale etc
canvas_restore(c) //State 2
..... Translate scale etc
canvas_restore(c) //State 1

Cheers

[Phil999]

canvas_save(c) // State 1
...... Translate scale etc . . .
canvas_save(c). //State 2
...... Translate scale etc
canvas_restore(c) //State 2
..... Translate scale etc
canvas_restore(c) //State 1

nice instructions, good to know.

An OSC sender in Reaktor's lamps. That's what I was looking for last night. Will search again.

Yeah I'm still not very familiar with Reaktor yet. This audio to event converter ... would it be possible to intercept the audio from the Ensemble, convert it to an event, sent that to Lemur, feed the Scope object with this data, and make it look similar? Only asking. You know, when you asked if scope data is sent I thought what is that? No synth sends such data. But with Reaktor ...

These LFO LED's already make a huge difference. To have them react exactly like in Reaktor, for internal and external clock, is very helpful for the user/musician. Transferring the rest (Sources of Uncertainty, Sequencer, envelope sources), some design details, and this template is in an already advanced state. OK, tidying up is not done yet. And about scrolling ... I still think two Lemur interfaces are better. Faster and more reliably to operate. Will still consider scrolling, since there's more than one way to do it in Lemur.

Aalto and West/Reaktor are somehow more difficult to handle because of their large GUI. All parameters are important, all of them should be instantly accessible. Diva, which has much more parameters, could be packed rather easily in one Lemur interface, thanks to Diva's clever GUI and MIDI mapping options. Larger GUI's need scrolling or more than one interface, or container tabs, or a combination of it.

Thanks you guys. I'm a bit slow with learning, but with your help I learned quite much in the last month. Which inspires me to do more myself. There are a dozen projects that can be continued or improved with this new knowledge.

[Macciza]

Phil
In Edit mode in Reaktor, right click an element and select Show in Structure , in other pane is best often
Most of the stuff is at the first level on left, look for OSC Sender objects . . .
Have done most of that stuff now, will do sequencer and will send an update soon
Re Scope it becomes an issue with audio rate and control rate, but I guess you could maybe do something by filling an array with values in between control cycle and send that out perhaps . . .
Yep definitely many ways to skin a lemur . . .
MM

[Phil999]

yep let's leave the scope for now. The idea of sending audio level data from Reaktor to Lemur is thrilling. Since Reaktor is also a plugin and easily accessible via OSC, I can think of many applications.

Now West// 1.1 is out, with new modules. Very interesting, I like the way it is going. And somehow expected, as Icaro Ferre already made a hint about new modules. I left some space open in the second tab for them. Now I definitely left the idea behind of only having a working, functional Lemur template. When the possibilities are there, it should also look good. In a functional way I mean. So that the performer has a good overview of what is going on, and instantly make choices from a familiar, clear surface or interface. In a couple of days I think the version with LED's should be ready. Needs some additional time because of the Ensemble update.

The help and creative ideas in this forum is so big that we cannot stop here. There are these simple blue buttons in Buchla synthesiser systems, now I need to have a two-state button in Lemur. Only slight shadow and reflection, but realistic enough. In Reaktor it looks good and is still very simple. This is possible in Lemur, may just need some time to develop. Macciza, you can take a well deserved pause. I think I can handle it (*gulp!*).

[Phil999]

first need to look at performance ... dozens of canvases on "always draw" is a bit much for older iPads. So I was trying with "on demand" drawing. A test with 192 canvases (the ones in the attachment, duplicated) results in still acceptable performance.

How do you get the gradient in the little knob drawn "on load"? See attachment.

[Macciza]

Hi Phil
Standard way would be to add an init / onLoad script . ..
This could set parameters etc then call canvas_refresh()

This projects progression raises a few optimisation ideas . . .
By the looks of it you are wanting to draw a small knob/lever canvas then move that via Fader.x control?
Or are you thinking to get touch data from the grid background?
I'm wondering which of the many possible permutations is optimal???
And I'm guessing you also want to do a bunch of them . . .
Will have a bit more of look at some point . . .

Also, just noticed a slight unoptimisation in the code id sent previously ...
This

Code: Select all

for(i=0;i<13;i++){
canvas_beginPath(c);
canvas_moveTo(c,2,i*10+6);
canvas_lineTo(c,40,i*10+6);
canvas_stroke(c);
}

should be

Code: Select all

canvas_beginPath(c);
for(i=0;i<13;i++){
canvas_moveTo(c,2,i*10+6);
canvas_lineTo(c,40,i*10+6);
}
canvas_stroke(c);

This way we are making one path with subpaths and stroking it, rather then making multiple paths and stroking each one . . See Canvas tips thread . . .

Will have a bit more of a play and post some more stuff
Cheers

[Phil999]

yes I think moving already drawn canvases might be a good idea. Only the knob canvases need "always" draw. And the LED canvases. The rest could be drawn only once at project load. Then I know how the entire template will perform, but first I need to have all 'passive' canvases drawn onLoad correctly.

Tried with init scripts onLoad and canvas_refresh(), but somehow it does not work? I'm having generally problems with onLoad, some things aren't logic, for example the custom menu's labels do not appear despite an init() script. It's an older problem, often been struggling with it, and don't remember the solution.