Blocks: your verdict?

Thanks Salamander for the replies.

Just one clarifaication about the A B Buttons.

I have been moving the whole stacked macro, so all elements move together, but when i hide the line box, they all jump together about a cm upwards and left. this is when i am having difficulty lining them up. is this normal or, am i missing a trick with this?

Yes its was the concept of how the GUI was being in Primary, what i meant for the paradigm. cause its a shame to have all the components in the Blocks so interconnected they can't be remixed as easily.
Just as an example its very easy to take the entire contents, or just parts of an R5 enesemble like Spark and mash them up with any other, all in a new interface. relativley easily, so remixability and mashing , skinning was faster in R5.

Just one last question.( serious). is it with say 6 months or a years practice possible to replicate one of my horrible synths complete with a nice abombinal UI just in Core, and using only the Blocks Template? or would it be too different an environment to replicate them in.

 

So if Multi-core is too difficult, and even if it were implemented, it seems also the DAWs we use could not run in real time any ensemble that was over built 100%. This mean both a whole new Reaktor-esque platform is needed? and i assume it would have to be designed from scratch. aswell as the DAW's code so they could run them in real time.
Thats wild. I am sure there would be a way round it, like some script in Reaper could bridge a few cores to run an Uber ensemble in realtime.

 

pretty irritating, huh? the trick i related earlier works with the frame turned off, so you can move the whole stacked macro at once without dealing with this problem. if you want to use the mouse, it is really hard, i agree. not sure what the technical issue is with that. i think they jump up 12 pixels and right 8 pixels but i may be remembering wrong. so yo can place it in the right place, then move it down 12 pixels and left 8 pixels, so when you turn the frame off it jumps to the right position. kind of a PITA and the 'jumps' seem to only happen sometimes, so i use the other method now.

i mean, i get it, but at the same time, just hacking out an oscillator from monark was pretty difficult compared to just using the monark OSC block, so i think there's been movement in both directions there.

i think the problem that you personally would run into would be CPU. core can be substantially (like 10x or more) faster than primary for certain tasks but unfortunately the blocks framework doesn't really take advantage of that. in fact, blocks is really inefficient because each instrument has to translate between primary and core, which takes a lot of CPU.

i would suggest starting to work with the higher level core stuff (oscillators, filters, etc) you could learn to use them the same way that you use primary stuff to begin with. at first you can just replace a primary oscillator with a core cell wrapped around a core macro oscillator. once you get used to it, you can put all of your core stuff into a single cell (more efficient). from there you just start using it for more and more tasks.

personally i basically ignored core for about a year. i kept opening it, getting confused by all the weird diagrams and stuff without names, and giving up. take heart though - there are only a total of like 31 components that make up all of core (actually there are a bunch of new ones in R6, so it's probably like 40-45 now), so you learn what everything is pretty quickly.

 

cheers Salamander. likely in the future i will use it more. for now i think i nailed an awesome in between that works so i ain't gonna break what don't need fixing.

Still I really do have to have the abiltiy to grab all/any elements in a oner direct on the UI and shovel them round in ways others don't. I would never have made any of my ambiitious R5 designs otherwise. Always having to go to structure view just to grab a button is a workflow destroyer.

I will try to explain better. if i have a project with big GUI i am looking at the full screen and my eyes need to be able to see the FULL GUI to be able to place the elements with style in the right place. If half the screen is covered by the structure view, my eyes can't place the objects aswell cause only half the GUI is visible (yes its an arty farty complaint), so i need to start phaffing with dragging the borders up and down. every time i need to SEE and every time i need to select. Its a major inconveince that is only a problem for my style of building, but i will point it out anyway.

Good news.. i think in theory i have a way round the AB mod thing. I am gonna just have a master switch for AB that is connecting to all AB's. then i am gonna hide all the individual ones. Means just moving 1 set not 15. And as a bonus it will be much neater on the UI aswell.

just noticed Unitron...very cool. liking all those scifi mod rings. nice job!

 

About the GUI elements i also find it very annoying how it behaves when you turn the macro frame option off.
It does jump 12 pixels up and 8 pixels left when you turn it off so you have to move everything 12 pixels down and 8 right if you want it back to the original place.
One nice trick to select all the elements you want is to just create a normal knob or button and then go into structure view select it and everything you need to move,if these are inside macros you just select the macro with the knob or button,go back into panel view,grab the button,knob and move everything where you want it to be.

 

Would turning block instruments into block primary macros help? Or is the overhead to translate core between primary macros just as high?

 

Cal, you might like to try this and see if it helps you? These are basically my workarounds to get around what is a very poor graphic implementation. (I am not complaining mind you, reaktor is an audio haven, not a graphics editor). Pardon me if this stuff is already well known by everyone, but posting this on the off-chance it helps someone.

1. get the ensemble to view the GUI and the structure at the same time. I usually use horizontal, but whatever rocks your boat. I often open the structure pane by right clicking on the graphic element i want to move in the GUI and selecting "Instrument Structure in Other Pane". This way it finds it for me (usually) really quickly.


2. Select all the elements you want to move on the GUI. I just use shift + click to multiple select. I typically use structure view to choose items, GUI view can make for major headaches with knobs with shadows, overlapping images and etc. The higher the level in structure view, the more you grab at once and the positional relationship between GUI elements stays the same.


3. Now HERE is the real trick. You must not click anywhere else than the following locations or you will have to start again
a. unlock the GUI by clicking the lock icon (if it is not already unlocked that is)
b. click once only on the GUI breadcrumb-trail bar where i have written on the following attached image - anywhere on that bar but I typically click about where I have placed the word << here >>. This single click changes the focus of the arrow keys on your qwerty keyboard to work on the GUI rather than on the structure. If you see the structure elements deselect, go back to step 2 and repeat the selection process.


4. Now you can close the structure view using the little cross icon top right of that pane and proceed to move all the graphic elements with the full GUI window available to you. You can make complex selections of distributed elements via structure and GUI, and while they are all selected behave as if they were grouped. Note that if you click ANYWHERE you will deselect everything though, so only use arrow keys and modifiers.

5. I typically turn "snap to grid" OFF so that I get access to pixel-level adjustments. I hold shift while I press the arrow keys to get large movements, and arrow keys with no shift modifier to get pixel-level movements.


Hope that helps, I am new here so just dipping my toes in the water.

 

Try the star icon for a time saver, Cal. It saves different panel setups so you can jump between them.

I like your idea for the master switch. I just tried it out, it's actually pretty easy. Go into any block and get the "Mod Assign" macro out of its panel macro. Put the Mod Assign macro into your ensemble, or its own instrument if you want. That gives you master A/B buttons to hook up to any block.

To control a block with this:
Make a new input on the block you want to control
Connect that input to a new input into the panel macro
*Unhook the panel's current Mod Assign macro from the controls
Replace the connections using your new input instead.

*edited, don't delete the current Mod Assign macro, just unhook it from the controls. The buttons are still useful to show the level of modulation reaching the block.

 

My master switch, controlling a few Paul Mcartney filters.

 

I guess I misunderstood what you need to do, but a similar process could be done for mod sliders as well. You could replace the sliders with knobs and build a cool little control station. I'm looking forward to seeing what you come up with.