Operator feedback in the scheduler event domain
Comments
-
You had removed the ..SR default link to parent SR here:
And edited this one changing it from ..SR to SR (I explained that this would break it in an earlier post)
Not sure what was going on in the strange macro here, but I replaced it with a multiply, because that's all the macro was doing anyway:
0 -
Noppes , the point was that I WANTED to change the masterclock name .
I know it's just a mulitplier and I know that it works when the masterclock is called SR .The point was that once the masterclock was renamed , the mulitplier didn't mulitply the feedback anymore ,even when it was in a new macro that fell within the scope of the newly renamed masterclock .
Here is it again , do NOT change the name of the masterclock called "this"The macro called 'Hello" is working correctly since the scope state is : connected , and it works perfeclty as a gain mulitplier but once it's used for routing operator 1 back to itself it doesn't anymore
If you looked at the giff that I uploaded it's all documented , but I will do it again
I a nutshell , I renamed the master clock to a new name called "this", and made sure that both operators fall within the scope of that new name .
You said that for implicit feedback , it needs to fall within the same scope so I created a new macro that falls within the same scope , that macro is called "hello "
The first 10 seconds of the giff show an operator mulitplied by this macro ( gain mulitiplier ) straight ot the ouptut , result is a working osciloscope
Conslusion : the macro works
The last part of the giff shows operator goimg into operator 1 , and fed back to itself , this time the macro is used a gain mulitplier for operator feedback but it doesn't works
Hope it's all clear
Please have a look at the giffWhy is that ?
0 -
It's because you created a new clock and gave it a new name.
I keep telling you what to do, and why, and you keep insisting on doing it differently, but the stuff that doesn't work is the stuff you are doing differently. And yet you persist.
The answer to this particular question is on the first page of this thread.
0 -
You cannot 'rename' the 'master clock' (whatever that is?)
You can 'override' the sample rate clock bundle 'SR'. You override it by packing some other clock, sample rate and reset into a bundle and calling that SR. Within the scope of your new distribution bundle SR, anything that refers to the sample rate clock will use yours instead… including implicit feedback…
Don't use implicit feedback, it's bad coding style.
If you create a clock bundle, and pipe it through a bundle distributer called 'this', then all you have is a distribution bundle called 'this' with a clock in it.
0 -
That's what I meant , I override the master bundle
Then why doesn't the multiplier work for feedback but everything else does ?
Did you even look at the giff ?0 -
That's what I meant , I override the master bundle
That's not what you did though.
You made big deal about renaming. Then you created a bundle distributer with a different name.
0 -
I added a latch [-1] (delay of 1 sample) to get rid of the orange cables and it works so i guess as colB said orange cables are bad as you don't know how Reaktor handles it. I also had to modify the latch with your "this" for the clock inside it.
0 -
Another question .
If I have an iterator range 1024 run by the gui clock @ 20 Hz , that's a constant stream of 20,000+ events .
How come the mutlitdisplay or any other event module are able to process this accuratly given the restricted top event rate of 3200 Hz ( primary only )
The mutlisdiplay handles this all flawlessly , just something I'm curious about .0 -
That's weird , I am sure I did that before and it still wasn't working .
Now I see that you've also set it to non-solid mode
So in the end , it was not the naming that was wrong , it was the gain macro set to solid .
Thanks0 -
There was no need to another macro with z-1 , since the"Hello" macro was just a gain multiplier ( also functioning as feedback coeff ) .
So in the end , the renaming was done correctly
All that was required was non solid mode fo r the "hello "macroand to get rid of the implicit feedback ,reverse OBC of write read order to get an explicit 1sample delay
inside the "hello " macro
0 -
The latch[-1] in the library is always non-solid and the info states it is made for feedback structures. I always use this to get rid of orange cables,this way i decide where the z-1 happens.
1 -
There was no need to another macro with z-1 , since the"Hello" macro was just a gain multiplier ( also functioning as feedback coeff ) .
Yes, initially, the 'hello' macro was just a multiplier - everything else in there was completely redundant.
So in the end , the renaming was done correctly
There was no renaming. You packaged up a clock into a bundle, and put it on a bus, and gave it a name. You didn't rename anything. There is no renaming happening. Renaming busses is not a thing in Reaktor it's literally not possible.
If you change the name on a scoped bus distribution module, you are telling the bus distribution module to start distributing on a different bus. If that bus doesn't exist, it will be created.
(If this seems like a pedantic distinction to someone, then they don't understand how busses work in Reaktor)
Generally, there is nothing wrong with creating a clock and putting it on an arbitrarily named bus, it's a useful technique. However in this specific case, it's non-optimal, and particularly in the context of your code from earlier in the thread with implicit feedback (that you couldn't get to work, and were asking for help with) it just doesn't work, whereas overriding the SR clock does work.
All that was required was non solid mode fo r the "hello "macro
and to get rid of the implicit feedback ,reverse OBC of write read order to get an explicit 1sample delay
inside the "hello " macro
hmm… all that was required to avoid using a z^-1 macro was to turn part of the hello macro into a z^-1 macro… seems like a perversely contrary solution?
which of these two pieces of code is more immediately understandable to others, or particularly to the author in two months time?
1 -
That cheeseburger macro made me laugh! 😅
0 -
-Quote-
Renaming busses is not a thing in Reaktor it's literally not possible.
-Unquote-
If you go into the clock bundle and Rename the "C" to "T" , then everything that relied on the clock SR.C will not work
If you then rename everything to SR.T , it will
Is that not renaming ?
Unless we're lost in translation …Here's giff of the process ( maximize )
Or let's change the R to NOTHINGBURGER and every SR.R. to SR.NOTHINGBURGER
0 -
If you go into the clock bundle and Rename the "C" to "T" , then everything that relied on the clock SR.C will not work
If you then rename everything to SR.T , it will
Is that not renaming ?
We were talking about busses. I was explaining that it is not possible to rename a bus in Reaktor Core.
Now you are saying... "HAH look see, I can rename a fibre in this bundle! GOTCHA!"
…the thing is, bundles are not busses.
So which do you want to learn about? bundles or busses?
FWIW, it "looks" like you can rename fibres in bundles, but you can't really do that in any meaningful way. To 'rename' a fibre, you must individually edit all references to that name replacing it with the new name. So you are really completely replacing the fibre with a different fibre (with all the associated error prone busy-work that entails), not renaming it.
NB. You CAN rename a QuickBus. When you edit the name of a QuickBus, all reference to that QuickBus automatically update to the new name. It's the same QuickBus, you just changed the name of it. That is renaming, but that is only possible with a QuickBus. A Distribution Bus is a different thing entirely.
0
Categories
- All Categories
- 18 Welcome
- 1.7K Hangout
- 68 NI News
- 903 Tech Talks
- 4.6K Native Access
- 17.9K Komplete
- 2.2K Komplete General
- 4.8K Komplete Kontrol
- 6.4K Kontakt
- 1.1K Reaktor
- 408 Battery 4
- 929 Guitar Rig & FX
- 470 Massive X & Synths
- 1.5K Other Software & Hardware
- 6.4K Maschine
- 8.2K Traktor
- 8.2K Traktor Software & Hardware
- Check out everything you can do
- Create an account
- See member benefits
- Answer questions
- Ask the community
- See product news
- Connect with creators