Features you'd like to see in Blocks

Thanks for clarifying, I misunderstood your initial post. I see your point, in some cases it would be neat to have information about the modulation sources on the panel. However, when working in Split View, I find it pretty easy to keep track of patches, especially since connected wires are now highlighted when you click on a module. To be honest, I think it's even more convenient than tracing back patch cables in a big patch on a hardware modular.

 

agreed - but it would be great to have the option to colour the wires.

sowari

 

Yes, Yes, YES!

Let me iterate on that.

Implement a new connector system into the Reaktor UI, that is visible as wires and has the possibility to have its connection state saved to the snapshot system.

This connector system should be implemented as feature of the primary marcos "Terminal/In Port" and "Terminal/Out Port"!

These 2 ports should have a boolean flag in their view or function tab to enable this feature and make them visible in the UI, which has to default to false, to not destroy legacy ensembles.

Normal wiring between primary marcos or instruments via in and out ports would act as default wiring of the blocks or the insides of a instrument.

The wires you draw between them in the UI version of the in/outs would overwrite the default connection. This works for U-HE instruments(ACE, Bazille), this will also work for reaktor instruments and blocks.

Another thing:

It would also help very much to have a bundle in and out on core macros to interconnect them with each other using bundles.

Best Regards,

Psychotronic

 

Quick recommendation for those who want to have per-snapshot cabling: check out my 8->1 and 1->8 switch Blocks. The state of the "STAGE" knob is saved with snapshots, so you can use those to select one of 8 routes for a single input, or one of 8 inputs for a single output. That's been my current workaround for the time being.

 

It's not so simple how you think:
1st: If you want compatibility to older ensembles the paradigm of instruments has to be conform to existing paradigm.
2nd: If you want to create such a wire system over the whole ensemble there has to be a new layer above all instruments.
3rd: every input/output of every instrument (block) has to „know” its absolute coordinates according to this layer and its current state, so there has to be a global managing of status datas which is no problem.
4th: Although there has to be a global layer, the access to blocks panel has to be always active! So the layer has to be in background.
5th: Rearranging or adding(deleting some blocks destroys the snaps!
6th: there has to be a new connecting system (like send/receives or terminal in/out ports) which is logically more global than instruments and is able to send and receive audio datas.

So it is no easy to create such a panel-wiring-system with a block-system which bases on instruments. It is possible if the blocks are macros and part of one instrument.

ciao herw

BTW: using ACE or Bazille are not the same like Reaktor Blocks because you cannot rearrange or add any modules!

 

I think my biggest request would be - time to work on CPU optimisation! I've used blocks in every single piece I've made since it was released (see my soundcloud below should you be interested) and I love it - but as my patches get more complex I find myself stymied by CPU

Oh - and for wiring - I can live with the separate patcher window BUT it would be lovely if when you are trying to connect to something off screen as you move to the edge of the patching window it scrolled so you can make long wires!

 

Yeah. Default it has to be turned off, all of the UI representations for in and out ports need to be invisible and disconnected by default. I already said that.

Sure.

Yes.

Yes. Like it is with ICs.

That is acceptable, there is no way to avoid that.

Yes. Just like ICs, but directly implemented to in and out ports.

Both should be implemented. If not, the block system is doomed for me. Which isnt really a problem, cause i'm able to create mod matrix macros that fix that issue for me, like i did on this one:

http://www.native-instruments.com/de/community/reaktor-user-library/entry/show/8652

But it would make me very sad to see the one feature not beeing implemented that would give them superiority over eurorack.

 

don't agree because there exists a simple system (modular framework) which you can use for creating your own modulars and patches, which can be stored as snapshots (wires on screen). Or you can use the ready made modulars with wires on screen.
So the REAKTOR Blocks are made with a very clear layout and prepares new users to get a start in grafic programming of REAKTOR ensembles.
ciao herw

 

ok, sorry...

 

Reaktor is not merely an instrument for the consumers of blocks. I certainly hope that NI doesn't go too far down this path of appealing to the non-technical. That said, the lock button is useful, but, a good fix would not be to simply fix what you find problematic, rather, it would fix the issue of locking U/I elements at a more structural level. For example, it would be nice to lock the contents of a container macro visually without locking the container. This way one could grab a knob and reaktor would move all of the locked contents maintaining position. That is, locking contained elements could be a property of all containers, e.g. macros, instruments, and could be set in the property window. Blocks developers could then set the property so that blocks consumers would be able to stay in edit mode without worrying about moving blocks bits around.

Note, I'm not suggesting that this affect the ability to edit, either for the developer or the consumer. It is a simple property under view for each container element that could be set or unset. When unset, elements of that container can be moved independently, when set, moving any elements of that container moves the entire container. This would allow developers to easily move smart knobs around without the current headache of turning on the macro frame to avoid nested macro nightmares.

This would also not affect the editing in the structure view, one could still drill down and edit at will.

 

I still hate this painting of the users of blocks as "non technical" - they are a fantastic way of using the power of reaktor to get on with making music without having to spend hours "constructing"

All that said I strongly agree with your point - reaktor is strong precisely because you can deep dive and make complex stuff from low level components AND you can fire up a synth someone else made (or that you made another day) and twiddle a few knobs and get going and I certainly don't want to lose either ability, they both have their place in my music making.

 

A visual browser.. Or when hovering an .ens you'll see an image of it..

 

Panel routing.. When you go into edit mode you would see all ins/outs per block appear at the left/right side of the instrument just as you see them in structure view? Combined with the ability to draw connection wires between the ports in edit mode..

 

Insert Blocks from the contextual menu..