mb dynamics

interesting is: when i read this thread very quickly with a raw overflow i saw this screenshot only for a moment and recognised it as similar to mine. What did i really saw? THIS:
?????
I saw signal flow from left to right, ordered wires from top to bottom. That's my programming style.
Reading the post i remembered and i looked again: oh it is mine.
So a consequent programming style is something which helps enormously.

Now looking to the structure i see the unmeaning names of inputs/outputs/quickbuses. I see {b} which is typical to partials framework's multiplexing system. Partials framework is the main part of my GUI-programming style so i know what it means. But what are c#, o#, i#, [], $?
As some people use partials framework it is not a good style to change [] to index, $ to value, id? to message identifier.
So something has to be cryptic. BTW i don't like „$” too .
But what about c#, o# and i#? I could write address of container c, address of output base, address of input base. I don't think that (very) long names are useful. So what i have to do: write a workbook - in German (my language), in English (for interested users)?

I made a short compromise for interested users:


BUT how many users are interested to read this boring info? What does container c# mean? What about length # = 3. Why do i choose message id= -5 and not +5 ??? It only helps me to understand after five years.
So that will be strange for ever if i don't write a book of 1000 pages or if someone asks me face to face.

My personal informations are comments (here in primary structure):


Would be nice to have same comments inside core too.

 

digit8: downloaded for further study. Lots to learn from here. Lots of Primary and... where's that Parser macro? Oh, way over there in a corner.
Parser macro is a goldmine of information about a whole array (no pun) of core problems/solutions. And I meet my old friend, MIDI processing macro 'fancy processor 2'! Reusable code! Now if only you could put it in a library, include the library, and call its functions! Too much to ask I'm sure.
The whole bytebeat world was invisible to me till now. Looks like the user types in opaque 'commands' and gets C64 music out. Retro to the max!

 

yep, i also tend to see flow from left to right and stages of data vertically aligned. actually your stuff is much more readable for me now than say two years ago, and also more readable than other stuff, because we order things in a similar way. i don't like long names either. i don't know if visual, but i'm a very geometric person -i code, compose, mix geometrically. i usually write without caps because i don't like the false geometries they impose to text (?). i also don't have very good vision, reaktor fonts are very small and the screen is 80 cm away from my eyes. long names don't help me at all -they become noise. to read the usual randomly shaped reaktor/max patch i have to spend hours getting close to the screen to read names and try to untangle the flow. that's why i can't compose with supercollider -as powerful as the language is, the total disconnect between the music you're making and its representation is a wall for me. i need to see the music. when i pick a short name like "g", it becomes an abstraction, so i don't need to read it. i just see it and i know what it is in the picture. it doesn't help me to call it "filter gain" or "gain coefficient". i always detach filters from parameter calculation, so all filters have a g that may come from frequency or from time -there's no confusion. if long names make everything big and misaligned, it's doubly worse -they're noise, and they break the picture. most of the times i don't name a macro, it's because what it does is defined by its ins and outs:

this takes band levels (lvl), thresholds (thr), all other band parameters (...) and average weights (wgt), and outputs average levels (avg) and live gains (g', as opposed to static gains g). i could call it "average levels and live gains calculation", which just repeats what the ports are saying.

i know this makes the code difficult to read for other people. i get {} now, i often use # for integer selectors, ? for conditions, ! for triggers, but looking at your code i can't have the least idea of what b, c, i and o are until i trace them back to something concrete, and it's a very long trace. but it's still easier than diagonals randomly crossed through big empty spaces between randomly placed modules.

 

Herw,
Your programming style is a model for anybody wanting to write coherent core code. It's beautiful too. Easy on the eye is important.
I agree with Laureano that shape (in writing Core) is very important. If one thinks visually, and to some extent we all do, then clarity in code should be mirrored, if possible, in the visual layout of the code. Your code does that, and I can read it, even with arcane symbols from Partials_F. Dein Deutsch ist auch sehr klar und ich kann es leicht lesen. Alles Gut. Danke!

 

I have similar vision problems, Laureano. I'm even further away from my screen than 80 cm. So I have constantly to use either the Zoom-It tool or the built-in Mac Zoom (Command-Alt-8) to read almost anything in Reaktor, but then have to zoom out to find anything else, like the Properties tab. So long-names are likewise noisy to my eyes without zooming in. I do like CAPS because I can read them without zooming, but of course they take up too much space sometimes.
Over the years of writing thousands of lines of music-related code, one comes to a point where one has one's own abbreviations. They are instantaneously recognizable to us (not necessarily to others) but we would be foolish to abandon such powerful shortcuts to our own understanding.

Like colB I believe in self-documenting code, but this can take a lot of decision-time in the effort to balance clarity with brevity. Unlike colB I love big comments. I love breaking up written code with written explanations. I'd rather spend a short amount of time reading an explanation that clarifies intent and tactics than have to ferret these out by reading someone else's code, Reaktor or c++ or whatever. (Which is why I find the exclusion of 'Comment' type in Core so annoying.)

Single-letter abbreviations I have never used and never will. I don't mind the Partials framework signifiers: !, #, $, once you learn what they mean. But I was completely lost when I first read up on Chain Iterations with -+ and +-. Schmitt/Zagler notation seems a bit precious until you understand what the telegraphic symbols mean, but then the effect of their brevity turns around, and seems economical, efficient.

 

i often prefer comments to long names even in written code, if they're going to be involved in long formulas or nested calls. if a one-line formula becomes a three-line one because of long names, so i have to search for the operators to get what it's doing, long names are not helping.

 

As you imply, the thing about no real comments is you have to look at all the code, carefully, just to figure out whether the code you're looking at is of relevance to you. I much prefer to scan through comments, which give the flow of the code, and settle on and study the parts that I need.
But, as Sly and the Family Stone so eloquently put it: 'different strokes for different folks.'

 

Both you and Herwig have implied that the alternative to single or double character abbreviations is whole sentences. Neither of these is particularly useful. Good descriptive names are the best. If the labels are too cryptic for someone who's not you, they will be too cryptic for you in five years after twenty other projects. If they are too long with multiple functions and side-effects strung together, it usually means that the code is not factored properly.

Comments can be problematic in themselves - much better to have code that is readable and keep comments to a minimum. Comments are useful to explain intent and occasionally to give details of functionality that might not be obvious even from well factored and labelled code. But comments get stale easily because it's extra work to update comments when sections of code are changed, so it's easy to leave them out of sync, at which point they make the code harder to understand, not easier. Self documenting code doesn't get stale in this way (at least not as easily)

------------------------------
Here's another example of some code that would be very difficult to understand if all the labels were two or three letter abbreviations, but although I've not actively worked on it for a couple of months, and it's a very large project, I can understand it easily because it is well factored and well labelled.


Linear processing DSP stuff maybe doesn't need this to the same extent because it is comparatively simple. I have various synth projects where it's really just a chain of processing sections that really only have rudimentary labelling and commenting because there really isn't anything much to define, it's just a linear sequence of processing algorithms, but even then, it's better to call things what they are. Here's yet another example, this time part of a fairly straightforward polysynth, but most of the stuff is named sensibly (IMO) few cryptic abbreviations, and most of the macros are labelled...

There are some abbreviations like fbk for feedback F for frequency, so fbF is ...maybe the most cryptic being 'muxF'. mux stands for multiplex and F is frequency. This is a juno inspired synth and junos multiplex some of the internal control voltages, so I was experimenting with introducing artefacts at that frequency to see if it improved the authenticity... if it was 'mF', I would have had to dig into the structure to work out what that was for... and I have no idea what 'fd' is because it's too abbreviated!

 

hehe, the top few levels of that project are a very bad example of how to arrange things - unnecessary layers, and some that should have been factored further... one macro is even called onion (lots of layers) and after re-factoring, became completely redundant, but I have a silly sense of humour. I think where it really matters in terms of understanding the code, I did put some effort in.

Yes, but it has it's own thread, so lets not get into that here

 

well, it's not like i'm a fan of one-letter labels either. i was just pointing that different mindsets benefit from different things. different projects too. most of the things i've done are quite linear, and those which aren't are rather small. i get that if you're making actual algorithmically complicated stuff, well yes, you may have to be more explicit. but then, i can't solve those things in the code anyway -i draw them on paper, then i code them. i still need to formulate them graphically. last year i set to rewrite two ensembles i hadn't touched for a while, and it wasn't a breeze, but short names were much less of a problem than generally ugly code -i simplified them a lot. i still prefer to call things abstractly when the context allows it. if there's a clear two-dimensional space, i'd rather split it from its context and call dimensions x and y. if there's one time or one frequency involved, i'll call it t or f. if there are many but they're not functionally distinct, then i just number them. in a context of dynamics processing, thr rat rng k att rel are very usual suspects. i prefer to granularize the contexts so that relations are shown, rather than make distinctions in text. i don't think in text -to gather information from text i have to mentally or physically translate it to diagrams. some time ago i said that when i code in reaktor i feel more like making a device than properly programming. of course that goes more easily for linear stuff than for a parser. see your example with the tonnetz processor -you used the names agreed for the problem domain. why are those names agreed anyway? if i were faced with a tonnetz sequent for the first time, i wouldn't have the least idea of what P L R M H and T are. i'd have to learn it, and after some time i'd be thinking in letters. i do like that, i like to forget that P means parallel -it's just P now. similarly, when making this thing i liked to forget that tr (now trans) was transition factor, avg was average level or g' was dynamic+static gain. it's not good for archiving but it's good for thinking the way i think -words are a hassle for me. see how much i have to write to explain anything -it would be so easier if i could just draw it

 

I am thinking about opening a new thread in subforum Building with REAKTOR about structure design in core. Would you like to present your ideas too?

 

open it! let's see if it catches on.

 

ok today - add here a link. I think i will name it structure design in primary and core.

 

done:
REAKTOR Structure Design in Primary and Core

 

You can use the info tab in preferences for longer text descriptions.

 

YES - please add to the linked thread.

 

Done!

 

"v1.8.1: Revised the names of code elements to make some obscure parts a little more readable. Small code simplifications."
The virtues of civil conversation...

 

amen!

 

I do have a question, Laureano. (I've looked at your doc site and have enjoyed reading and puzzling over math equations. Looked in the belly of the beast again, too. Too bad my math skills got so rusty!)
So when you make the kind of changes you outlined in the recent upload to U/L, how do you know if you made 'good' changes?
What are your methods for testing the hypothesis: maybe this will function or sound better if I get rid of the BLEPs?
Is there something aural that confirms such a change, or something on a scope that shows cleaner results or something of that sort?
I ask because, when I'm making patches (more or less every day) I often tweak something or other and need to listen a lot to find out if the change improved or, well, ruined the patch. (Of course if I ruined it I usually can go back to the original.)