Project
West (Reaktor) programmer
Started by Phil999 on .
Sign in or create an account to join the conversation.
Yup, got it - cheers fella. 
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.
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.
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
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
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
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
nice instructions, good to know.Macciza wrote: 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
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.
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
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
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!*).
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!*).
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.
lever2.jzml
How do you get the gradient in the little knob drawn "on load"? See attachment.
lever2.jzml
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
Will have a bit more of a play and post some more stuff
Cheers
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
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 becanvas_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
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.
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.
Ok
Yep have run into some init issues...
Probably linked to order of evaluation of stuff etc, something not initialised in time...
Will explore further for a good solution ...
Having lots of canvases uses a lot of space- 80 individual canvas sliders = over 50% , 80 in 10 canvases < 10%
Cheers
Yep have run into some init issues...
Probably linked to order of evaluation of stuff etc, something not initialised in time...
Will explore further for a good solution ...
Having lots of canvases uses a lot of space- 80 individual canvas sliders = over 50% , 80 in 10 canvases < 10%
Cheers
hm, must also have an eye on space.
Regarding init/onLoad I was thinking of a delayed load command. A canvas_refresh(c) only a few frames later, or half a second. That should work. Going to test that soon.
Regarding init/onLoad I was thinking of a delayed load command. A canvas_refresh(c) only a few frames later, or half a second. That should work. Going to test that soon.
Ok, I think I have it sorted . .
Following the previous thought of it being a timing issue in terms of the vars, a known an documented issue I applied a standard workaround.
In your init() script you need to (re)set those vars to ensure they are properly available to the following script, which makes sense . . .
Heres an edit of your version with some comments and a fully working version using canvas touch input
lever2edit.jzml
Will finish off and tidy up a multitouch multi slider version . . .
cheers
Following the previous thought of it being a timing issue in terms of the vars, a known an documented issue I applied a standard workaround.
In your init() script you need to (re)set those vars to ensure they are properly available to the following script, which makes sense . . .
Heres an edit of your version with some comments and a fully working version using canvas touch input
lever2edit.jzml
Will finish off and tidy up a multitouch multi slider version . . .
cheers
I see. Unexpected, because when the init() script is executed, the variable values are there ... just not inside the script. To me it doesn't make sense, but that has not much to say as I have no background in programming. Anyway, it's a working solution, thank you very much for that. Now I can continue testing which version is best for dozens of custom faders. Hope to get a release candidate with good performance and also fixed init() scripts for the custom menus this weekend.Macciza wrote: In your init() script you need to (re)set those vars to ensure they are properly available to the following script, which makes sense . . .
Edit: nice one with getobjectrect[3]. I was thinking about if this could be done, and it can!
now we got a nice custom lever with one Canvas object. 96 of those on an iPad2 give 39 fps. Problem solved I guess.
lever2edit3.jzml
Edit: hmm, but the LED Canvas objects do receive OSC with an expression. Will have to try more to find out why one is working and the other is not.
I thought this is simple routine, but I have problems with OSC i/o. Although I remember back it also didn't work with the canvas fader. Expressions don't work, oscout() doesn't work. I realise even more that the Canvas object is different in many aspects. Would be interested in a solution here too. Otherwise I keep the sliders, but I have also a problem to move the lever with slider.x. There are quite some things that are different here, regardless if the canvas is redrawing always or on demand.Macciza wrote: Interesting solution using the slider behind the canvas, but it can also be done natively in canvas without too much drama, again can send you a version if you want . . .
lever2edit3.jzml
Edit: hmm, but the LED Canvas objects do receive OSC with an expression. Will have to try more to find out why one is working and the other is not.
Yeah
"Methinks there be spiders here . . ." Something unexpected is happening . . .
Will have a look, had tested basic midi mapping and figured o/c would be fine
Did a few quick tests with unexpected results so there may be a bug or feature at play here . .
Will do a few quick edits and send you more soon . .
Cheers
"Methinks there be spiders here . . ." Something unexpected is happening . . .
Will have a look, had tested basic midi mapping and figured o/c would be fine
Did a few quick tests with unexpected results so there may be a bug or feature at play here . .
Will do a few quick edits and send you more soon . .
Cheers
the first original template with only sliders give 21 fps on an iPad2. 20 fps is still enough so I didn't realise that I was already on the edge of performance. That's something that worries me.
Really must find an OSC i/o solution inside canvas (that may even have better performance than MultiSlider objects?). Will experiment tomorrow. Doesn't have to be the final solution. And if the CPU doesn't allow it, I'll stick with the original version without any Canvas objects or maybe only LED's. Fast direct access to the instrument has still priority.
Edit: the LED's alone bring the performance down to 17 fps (iPad2)! Will have to replace them too ... or do all LED's with one single Canvas object ...
Edit2: ok with refresh() scripts and onDemand it goes up to 37 fps. Much better.
Edit3: now OSC i/o in canvas seems to work. I must have done some mistake yesterday, but I don't know which one.
Really must find an OSC i/o solution inside canvas (that may even have better performance than MultiSlider objects?). Will experiment tomorrow. Doesn't have to be the final solution. And if the CPU doesn't allow it, I'll stick with the original version without any Canvas objects or maybe only LED's. Fast direct access to the instrument has still priority.
Edit: the LED's alone bring the performance down to 17 fps (iPad2)! Will have to replace them too ... or do all LED's with one single Canvas object ...
Edit2: ok with refresh() scripts and onDemand it goes up to 37 fps. Much better.
Edit3: now OSC i/o in canvas seems to work. I must have done some mistake yesterday, but I don't know which one.
Hi
There are a couple of solutions available for the OSC just gotta decide which is the best but will try to send you the different options a bit later...
Yep as much as possible should be On Demand for best performance . . .
Will try to send something later
There are a couple of solutions available for the OSC just gotta decide which is the best but will try to send you the different options a bit later...
Yep as much as possible should be On Demand for best performance . . .
Will try to send something later
worked all night on this one, and now it looks not so bad. All LED's, levers and knobs in the template and still around 19 fps on iPad2. Before it was below 10 fps. All canvases are now onDemand. Removed all sliders. No problems with OSC anymore.
Wanted to post the last version, but there is some silly bug with the knobs, I'll try to fix that tomorrow.
Wanted to post the last version, but there is some silly bug with the knobs, I'll try to fix that tomorrow.
here is a work in progress. Not entirely functional, the menus aren't mapped, and the new West// modules aren't fully implemented yet. The knobs seem to work alright now.
https://onedrive.live.com/redir?resid=F483FC5764919285!985&authkey=!ACBUWS6JGfQRj00&ithint=file%2czip
The Lemur editor shows 60%. This is the amount of RAM that Lemur will use? I hope it is not an issue. As far as I can see the template works fine, it only takes some time to load.
Please tell me if you cannot download from onedrive. Haven't used that cloud service often yet.
https://onedrive.live.com/redir?resid=F483FC5764919285!985&authkey=!ACBUWS6JGfQRj00&ithint=file%2czip
The Lemur editor shows 60%. This is the amount of RAM that Lemur will use? I hope it is not an issue. As far as I can see the template works fine, it only takes some time to load.
Please tell me if you cannot download from onedrive. Haven't used that cloud service often yet.