I m using the monoflop node in x86 version to play an audio file, the time of its duration. the event is done on a bang
If retrigerable pin is not set 1, the output ON of the monoflop returns to 0 before the duration asked, and this is an unpredicatble manner. Needs to be tested on audio files of 60 seconds minimum. this happens in a larger patch.
hei karistouf,
i’m afraid i don’t understand what your patch is supposed to demonstrate. it is missing a subpatch.
are you trying to compare the timing of a monoflop to the timing/position of an audiofile? this won’t work because they are on different clocks. or did you mean something different?
oups… here it is joreg !
Déclenchement Sequenciel Audio Sur impulse.zip (5.9 KB)
The monoflop is used to play an audio file on a bang.
i’m afraid you’ll have to try a little more to demonstrate the problem you seem to encounter. that patch is quite a mess and doesn’t come with any instructions as to how to repeat the problem.
if you want help on this, please remove everything from the patch that is not needed to show the issue and add step by step instructions so that we can try to understand what’s going on.
quite a mess ? olalala…
don’t get me wrong, i like it’s visual quality. as an image. but the advantage a visual programming language has, that it allows you to place the nodes in a way that gives a hint about the programs flow, is not quite use to its full potential here:
1 Like
ah !!! ouf !
i m using distance sensors to manipulate sound and images. so this patch is just making play an audio file from a specifiic folder play when you bang on the impulse entry.
this will play one after the other each audio file in the folder.
the monoflop is there to play the audio file once the impulse has been done
i tried previously different approaches like an LFO running once, but monoflop is far more better for that job ( or i missing a node ?)
I hope this is more clear.
no idea really on visual ergonomy on that one, really
yours, sincerely, christoph
see, the point is you’re trying to show how the monoflop has a problem in connection with the timing of a filestream (if i get it correcty). a patch that demonstrates such a problem should not have all the stuff to play multiple files out of a folder. by sharing such a convoluted patch you’re asking quite a lot of us to dig into your thinking and understanding the ways you put things together for your very specific purpose.
instead, please take the time to isolate the problem you want to make us aware of in a patch as simple as possible so we get a chance to see what’s going on.
Hey karistouf, don’t feel bad, your patch looks way cleaner than some of mine, particularly during prototyping!
But joreg is right that it makes it WAY easier for others to help debug if the patch is trimmed down to just the problem elements. Also, in going through that trimming process, frequently I find the problem was actually an artifact of something else in the patch, or a behavior I had not properly understood and not a vvvv bug at all - the best outcome!
Now this may not be the problem at all, but just looking at that pic of the patch I notice that the period of the monoflop is being set by the output of a downstream node, meaning there is feedback, and that there must be a frame delay in there somewhere and the possibility for a timing gremlin to sneak in - like the monoflop getting triggered with an old time set, which then changes a frame later, causing an uncertain timing.
Thank you medidadog, yes, theres is still anoying time gremlin ( damper can be also a problem form time to time)…
:)
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.