"Previous event module" difficulty
Here's a case where the initialization produces note 69. As the module states it's a one time init number based on what you put in there, in this case 69.
It does exactly what it is suppose to if I input any midi pitch on the input except the first midi note "zero". If a zero goes in there a 69 comes out. If a 1 goes in, a 1 comes out and so on.
This is the inside of "previous event" module.
As you can see the value 69 is written into the read module during init. After that I see no reason the zero value on the top left input should recall the number 69, but it does. I'm using a laptop keyboard to act as a keyboard right now, perhaps that's doing it. Are there any strange problems using the computer keyboards as midi notes? Does anyone see a reason a zero input value should be any different than any other value?
Init
midi note1 8.41 hz
Midi note 0 played several times, continues to play note 69 or a440
Next I play several keys, eventually it starts working.
So I add a 1 before the module a midi note zero is now a 1 yet and the same thing happens. So it's not a 0 in causing the problem.
I've learned to not blame modules as it may work perfectly under certain conditions. Any ideas on what is causing this? This module drives the above module thru an event input. I took the Dup Flt out thinking it might cause the problem but nope. Same issue, however if I modulate the input up then back down to 0 with the Pm input, it works fine for a little while. Pm is a simply a master tune attached to a dial. The value is 0 before the Dup Flt unless its detuned, but even if not detuned it works a bit after playing with the detune and returning it to 0. This is bizarre indeed, any ideas? It does work fine with the dup filter removed. Seem like an event problem of some sort.
I combined the dup filter and the "previous event module together in one macro, the dup flt is the first stage. Can anyone see the problem. I hooked it up to my keyboards and erroneous notes sometimes playing up the keys actually plays the keys downwards. Here's both:
This is the above module.
Best Answer
-
I did, it's here
That's you the dup filter and the previous event module unwrapped an connected together. There is nothing wrong with either of those modules (assuming you didn't break the when unwrapping them and joining them). So the problem must be elsewhere, but you haven't posted any of that context
A dup filter filters out duplicates. If you play notes into it, it will only send through those that don't have the same value as the previous one. So if you start hitting an A440, it will send it though on the first hit - assuming that the previous value was different, after that it will block any repeats of that value. That what it is designed to do. When the previous event module gets an event it sends out the value of the previous event, and stores the value of the current event.
So if you set up a rst value of 69 for the previous event module, and then start hitting a key that has a non zero value
- (depending on the external context that you haven't provided) initialisation will(or not) send a zero (or some other value if you had other code doing that) note value which will trigger the 69 value to be sent to the output, and the init zero value stored in its place.
- when you hit a key, assuming it's not the same value as the init value, the init value (zero) will now be sent to the output from the previous value module, and the new note value stored.
- if you hit the same key again, it will have a duplicate value, so will be ignored, nothing will happen
- keep hitting it, still nothing, because the dup filter works correctly
- if you hit a different key, now it will be allowed through and it's value will be stored in the previous value module while the previous value will be sent to the output..
- etc.
This is the expected correct behaviour from these modules, and it's also exactly what happens when I test it. here's a pic of the whole thing:
0
Answers
-
dup filter blocks subsequent events with the same value... so if the init sends zero, and then you keep hitting zero note, sending more zero valued events, only the init event will get through the dup filter.
0 -
That's all there is to it, but try interfacing it with the "previous event" module and all hell breaks loose.
This module is suppose to hold the 69 value during initialization before being hit by an event on its top input. Then it's suppose to pass all latter events and the 69 is gone forever. Unfortunately it doesn't work like it's suppose to when preceeded by the dup filter as shown above. You're pretty good with modules but my guess is your also good with the module logic too. I merged both modules in one macro trying to understand the problem but I don't see it, maybe you can. Don't worry about solving this issue unless your up for a challenge, It'll do me more good solving it myself. It was just a perk to speed up a scope trace at startup.
0 -
if the init value is 0, and the notes you are hitting are 0, then the dup filter will block everything except the init, so init sends the69, and then there are no more events because they are dups. value stays at 69.
Seems most likely cause without seeing the enclosing context.
1 -
This is more bizarre than I thought. Apparently any time midi note 0 is played an init event is sent out of the dup filter. Not sure how it all works but check this out. I put the module after the P ot F convertor. The frequency changes to A440 as it should during startup. Everything is fine but as soon as a play note zero the frequency is changed to 440; so it's obvious there is an init event sent down the chain and passes thru the P2F converter and initializes the module after it. Wow, bizarre.
0 -
Curious how the dup filter sends an init event. Is it possible the compiler is doing it since it's like a stop filter.
0 -
This pretty much proves that there is an init event . Play a 0 and get a 440
0 -
I think at this point it is obvious there is a difference between an init event and a standard event. The dup filter seems to generate an init event almost randomly, as shown below, playing randomly on the keyboard can stop some notes and pass others. It even passes note 0 at times. The system works fine without the "Previous event module", so I give up. I'll try another method, seems I have no choice. I'll remove the No Init and go from there.
0 -
The dup filter seems to generate an init event almost randomly
What you said here doesn't make any sense. Init events only happen during initialisation, they cannot be generated randomly. There will be something wrong with your code. But you don't post the code with the problem, so nobody can help.
0 -
I did, it's here, https://us.v-cdn.net/6034896/uploads/8UZ6T6EEE99A/dup-to-event-init.zip
Attach this to any of your ensembles that use the computer keyboard to play midi notes. Let me know if you don't have anything and I'll give you the entire ensemble. It's a big file and I'm trying to keep the storage down but I guess I could delete it so here it is. Hopefully it opens in the edit screen, play a few keys on the keyboard then attach the Dup filter and watch what happens. The notes are all wrong, etc.
It's in the glide section as shown,
Appreciate you taking a look at it, If you follow the glide output it goes into a core as shown here.
Open it up and look for this
open P to F as shown here and you'll see the "previous event module"
Now, If you notice , you can have the dup filter engaged with the previous event and it's messed up. Bypass either of the two and it works fine. Hope you find something, I simply wanted to use the previous event to speed the sweep of the scopes on startup. Also, it rarely works when exiting the structure screen after debugging. So turn the master clock off and back on to reset it, then it works.
You can turn the scopes on with the orange button. On the left is a choice to see the envelope of an operator or wave, I forgot to disable the "save with patch" switch setting in this version so if the wave shows an envelope on different patches that's why.
0 -
I did, it's here
That's you the dup filter and the previous event module unwrapped an connected together. There is nothing wrong with either of those modules (assuming you didn't break the when unwrapping them and joining them). So the problem must be elsewhere, but you haven't posted any of that context
A dup filter filters out duplicates. If you play notes into it, it will only send through those that don't have the same value as the previous one. So if you start hitting an A440, it will send it though on the first hit - assuming that the previous value was different, after that it will block any repeats of that value. That what it is designed to do. When the previous event module gets an event it sends out the value of the previous event, and stores the value of the current event.
So if you set up a rst value of 69 for the previous event module, and then start hitting a key that has a non zero value
- (depending on the external context that you haven't provided) initialisation will(or not) send a zero (or some other value if you had other code doing that) note value which will trigger the 69 value to be sent to the output, and the init zero value stored in its place.
- when you hit a key, assuming it's not the same value as the init value, the init value (zero) will now be sent to the output from the previous value module, and the new note value stored.
- if you hit the same key again, it will have a duplicate value, so will be ignored, nothing will happen
- keep hitting it, still nothing, because the dup filter works correctly
- if you hit a different key, now it will be allowed through and it's value will be stored in the previous value module while the previous value will be sent to the output..
- etc.
This is the expected correct behaviour from these modules, and it's also exactly what happens when I test it. here's a pic of the whole thing:
0 -
I sent the whole ensemble here. https://us.v-cdn.net/6034896/uploads/E7JF4XBSRV11/to-colin.zip
I was under the impression the previous value sent out a 69 during startup and all other inputs pass straight thru afterwards and the 69 is gone forever. I think that's true as that's exactly what it does do with the dup filter removed. I'm a bit tired right now but thought I better check in. I uploaded the "to-colin.zip" ensemble for you today. And some pics of where these modules are. Check it out and see if it's acting like you think it should. Sorry you didn't see that. Thanks again for helping. I'll check back later and see what's up. But read the tool tips on the previous event module, I don't think it stores a new previous value, but I'm dead tired right now and probably misconstrued your explanation. zzzzzs
Well, can't sleep, lol made your test circuit and re read the tool tips on the previous event value. This is what happened, I thought the module might output a 69 only once and that's exactly what it did do. If you read the tool tips they way it's written made it worth a try and it worked perfect until I put the dup filter in there. I thought the previous event was the 69 and not a previously stored value. It's a shift register in reality. So I already had it fixed in my head that I knew how the previous event worked. Now I re read it and sure enough it does store the previous value. As stupid as this was, this a perfect example of a great forum. I was fooled again. It must have been sending out a note then the previous event was flushed out from the steam of events and I never knew it. As soon as the stop filter was introduced the stream stopped. Very tricky but I learned a lot about events. In fact, I just started converting all audio inputs to events to lower the overall cpu; so something was bound to happen. Thanks again, If you feel up to it, can you figure out a macro to send a 69 or any number out on init and let everything else pass straight thru afterwards, please let us know. It's a good thing to have in the library, meanwhile I'll try to do it and post it if I have success. Thanks man, you're the boss.
0 -
This is what I wanted in the first place. lol Sends out the init value on startup and never again.
0 -
That's the best way if it works. One problem is if the 'In value's init event comes via some chain involving Primary order modules, then that would arrive after the 'Init value', and override it. Cross that bridge when you get to it though. If the merge works, use that - it's the standard approach.
0 -
I can't think of another way and so far so good. For some reason I can't delete that big file, to colin, pointless to waste forum storage, any ideas. Clicked on edit and found do method of deletion.
0 -
One thing I do like about the previous value module, it make it possible to detect a new value by comparing the input with the output. One use for it could be to reset a delay module when it's delay time is changed. I think you might need a latch preceding the input to hold the new value. Then compare the latch out with the output of the previous module and there will be a difference to reset the delay. Pretty simple.
0
Categories
- All Categories
- 18 Welcome
- 1.7K Hangout
- 68 NI News
- 898 Tech Talks
- 4.6K Native Access
- 17.8K Komplete
- 2.2K Komplete General
- 4.8K Komplete Kontrol
- 6.3K Kontakt
- 1.1K Reaktor
- 407 Battery 4
- 923 Guitar Rig & FX
- 467 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