Wishlist: panel tabs + 3 more(structure view)

already reaktor is the best thing i have, but
as i was making ensembles today i thought how much more
powerful the interface could be if:
1) you have tabs and click on the tab and a different panel appears,
this way the window space is a lot more managable--like an excel
spread sheet sort of

2) midi controller and poly aftertouch with ctrl#,note no. as a
parameter

34025) event "channels" like midi channels, only there's no limit (or
a higher limit) than the # of midi channels--maybe even audio
channels? like midi out module, but it would be channel out.

34026) all interface objects that transmit data (i.e. knobs, faders,
buttons, XY, switches) have 2 types of "interfaces" in the structure view:
one is the regular interface that you see but with no
connections --only for appearance in the macro,
the other instances just have the id of the object
and the data that is transmitted to/from it (so you can write
to it directly from events in addition to ctrlr, poly,etc.)
sort of making them "wireless"

numbered according to relevance with reality

anyway, thanks for reading this, and big ups NI!

elon

 

This is exactly what's on my wish list too!

- And adding to that I would like to have good old fashion
"patch cables" like they have in Nord Modular and Reason.

- and a "dropdown menu" panel object

 

some of the same wishlist ideas have occurred to me. tabs would be sweet, though you can use cascading instrument windows for a similar effect. but this is of course not nearly as handsome as tabs.

with regard to being able to control the midi controller # as a parameter, i'd agree with you, and i wish that reaktor had more midi output possibilities (i posted something about this yesterday), BUT what i've really come to wish for is a better control protocol than midi. when much of what we do stays on a single computer, midi has come to seem like a clunky sidecar. there are better controller formats built into dx8 (sonar's envelope control of plugins, for example). it would be great to use reaktor lfo's and envelopes to control bandpass sweeps in waves q10, for example, at a resolution that wouldn't be bumpy (or would be arbitrarily bumpy if you programmed it that way).

event channels: i'll second that. or if not that, some straightforward way to encode control data into audio data. otherwise it would seem to mean adding another type of output to the plugin formats. i was working on (a very primitive method of) encoding event data in audio last night, and i managed to get it to work between instruments within reaktor, but when i tried to get one instance of reaktor dxi to control a second instance of reaktor dxi in series, instead of the regular flat lines broken by dicrete steps of control change i should have been sending, sonar was seeing regular flat lines broken by discrete steps and quick trips (spikes maybe 20 samples wide) down to zero every 50th of a second or so coming from the first reaktor instance - the one sending control data encoded into audio. i was using one channel for gate info and the other for pitch info, just trying to send a scale of 1/4 notes, with changing velocity at each step. i've included a jpg of the recorded audio so you can sort of see what i'm talking about.

i'm wondering if anyone else has tried or, even better, successfully accomplished encoding event data into audio. if anyone is curious about what i was doing, i'll be happy to share the ensembles and a more in depth explanation of what i was trying to do, and what i envision doing. the problem that i am having, i believe, has to do with the fact that audio signals normally hit zero all the time. my control signals, however, might never hit zero, so either sonar or reaktor forces it down every so often. so perhaps if i can encode information in more 'real' audio signals i can realize my dream. maybe i should be reading some of those old bellcore specs (trellis encoding??). as for what use this type of thing would be would be, i'm not completely sure yet.

and as for the 'wireless' interface thing... i disagree, i wouldn't really want that, because it would make analyzing ensembles that much more difficult. i could envision losing track of what i am doing very easily. if you want to connect things, i think you should be forced to add in the ins and outs

 

ok, if anyone was wondering, i have not been able to reliably translate control data into audio that leaves reaktor and comes back (from within reaktor it is not that hard to do). the reason for this, it appears, is that reaktor audio out cannot simply stream bits at the sound card, but needs to shape its output into something that the audio driver can work with. so that audio out thing on the left of the ensemble structure screen is actually converting data from one format into another. but probably you all know this; i just had to bang my head into it a little. this makes it probably impossible to do what i want to do without at least knowing the technical details of the sound card driver api. in fact i now believe that the large number of different sample rates and bit depths that must be supported (along with the different plugin formats) would make it extremely complex to implement a controller to audio encoder, because each one would have to be handled very differently, and the encoding process would have to know in advance, as it were, what it is going to be talking to.

so i was thinking that i'd have to mess around with csound or max or something like that if i want that level of control (max for windows could show up at any time you know...). but i realized that they would have to have the same problem - certainly not an insurmountable one, but much more daunting than it first seemed. which is too bad, cuz i was starting to envision this packet-based protocol of control data encoded in audio invented by reaktor users for communicating between different ensembles, one that would just be begging to become a cross-platform standard. now i know why this hasn't happened yet. control data needs its own dedicated interface. so now i am left to beg cakewalk to implement osc. i sense the odds are long.

- brandon

 

simulate data channels "wish"...

yesterday i started playing around with multi client
tables again (stopped after mac users couldn't use my ens's
because of table files, and probably some other problems-- but
i'll try again)

you can:
write "runtime" data to an event table, and each time
data is written you pass the param_id (up to you to specify how params
are id'd-- i just use an int hooked up to rx) before the value
in an order statement.

even on an instrument with one voice you can twiddle many knobs(e.g. hooked up to 1 controller) and send tons of event data and each event passed with param#, then value will still magically go to the right place at the right time and never get "tangled" with other simultaneous events(magic semaphores?.

so it's:
knob,for example, hooked up to order which sends 1> param # 2>value going into order -- the param# goes into rx of table, value to IN
of table

you can use a sel_poly_at or controller # to trigger each time an event occurs for reading the same table in some other macro, far far away, in a distant place (but hopefully not a distant time.

so you can have almost wireless ensembles-- atleast with the events.

use multiple gates,on_velocity's and pitch in each macro that needs them to further dewire-- for me sometimes it's easier to work with less wires-- but only sometimes.

anyway-- if you want to be more "wireless" then i hope this helps

p_
|_e___a__
\
c_____e

 

do you have any examples posted?