Audio thread…
I hope also on audio thread we can do it right?
What I’m not quite understanding in the threads here is what the top level experience is intended to be. It’s one thing to be working entirely within an instance of one module. Here Rack has a pretty well-defined design for how to do things.
It’s a whole other thing if you’re talking about one module reaching into the internals of another module that you are not the author of and modifying its internals (be they params or anything else).
The design for Rack is that to make one module drive another module, it is via (virtual) voltage over cables, or by cooperating modules using the extender mechanism.
A module is free to have coupling between its params and have one param affect any property of any other param within that module. it’s possible that is happening in this case (no way to know, because we don’t know what actual modules we’re talking about here.
So, @Derozer, can you give us a higher-level description about what it is you’re trying to do?
Somethings similar to CVMap cited above, with differenti workflow, settings, options and such, which will fit some need I would like to have.
“I want to build a very advanced, complicated module. But I don’t known how”. Yes?
1 Like
And if thats true, should this discourage me instead of try, learn and accept che challenge? Note that CVMap does it directly on process without any sofistication, and I believe those module are pretty serious.
Anyway, the topic has nothing to do with that.
Just ask some tips for a better debugging, or a way to improve it.
Obviously I don’t know what is happing in your code, but you have to notice your process-method is on top of the call stack. I guess you are using an invalid pointer at some point or the call stack gets corrupted somehow.
You can assume calling setValue (or setScaledValue) from an audio thread is thread-safe as it is done in Core’s MidiMap the same way.
https://github.com/VCVRack/Rack/blob/8c6f41b778b4bf8860b89b36d5503fd37924077f/src/core/MIDIMap.cpp#L127
1 Like
Exactly what I Guess, thanks for the confirm.
Yes, its what is all about this thread. Dunno is the pointer. Call stack corrupted: such as? Example?
Very hard to say anything helpful without looking at the code. Can you show us your process?
Thread safe doesn’t mean unmodified on other threads though right? The issue here is thst you set and later get and the value is changed. I’m not sure why that’s a problem though. In multi threaded code it happens all the time if you aren’t locked or atomic,
I guess what’s the actual problem with the original code?
The problem is that nobody is changing that param 9 value, neither GUI or other actors.
It changes randonly without any external interactions (sorry, I should specify this in the main thread :P).
I see moving it just looking at the screen hehe
Could it be the smoothing?
From 0.4 fixed to 0.1 immediate value?
Also, if I set the param 11 to any value( (i.e. 0.38) It pass from 0.4 to 0.38.
So it seems somethings related…
I’m setting up Linux env, trying reverse debugging, hoping in some additional Infos…
There’s another thread which I think you sre in where Marc and I talk about how Param handle seems to be the way to do this in midimap. Maybe that helps?
What do you mean with Param handle? This? Rack/include/engine/ParamHandle.hpp at v2 · VCVRack/Rack · GitHub
Not sure about those object, but they shouldn’t store any param’s value, isn’t?
the midi map object uses those to maintain references to remote modules params for read and write access. Check the discussion here
Well, I don’t deal at all with MidiMap module, so this context I think is out of the scope.
I think that (maybe) I got whats could be wrong: basically, I pq->setValue in a for loop, for somethings like 3-4 params simultaneously for the same sample.
For what I see, setParam trigger the smooothing service, and I bet doing it for many params at time (as opposite to use smooth system for just one param, due to the gui limitation) could create some sort of glitch?
It seems that using setImmediateValue (bypassing the smooth flow) works (for the test I did, the problem seems vanished),
But maybe its just a supposition, and test are just luckly right now. Did you encounter this kind of problems before?
I still don’t have a perfectly clear idea f what you are trying to do but I shared it because I thought you using param handle to write your module rather than param quantity directly could solve your problem. It’s how the midi map module modifies other params which is I think what you’re trying to do!
1 Like
Smoothing with Rack’s engine can only be used with one parameter at a time (I think because its main purpose is smoothing mouse interaction). This could definitely be the cause of jumping values, but I don’t think Rack should crash.
Never crashed: just jumping values 