I’ve seen an option about reducing gain by -12 dB when going fast forward or fast rewind, I’m looking for a similar option to avoid muting when hitting stop or when stepping with cursor keys ?
I know this is a weird request, but for example I would like to be able to find out precisely the source of saturation when mixing several tracks, at a single sample scale.
I don’t know what you mean by “muting when hitting stop”.
While playing, sound is sent to the outputs, and when you hit stop, the main output gain is faded to zero so that the outputs end up at zero value too. And if I hit an arrow key to move to the next frame or image (I have a video in my project), the sound stays at zero. I’m using Ardour to work on motion data instead of sound, if you’re wondering why I need that 
This is too simplistic of a description for me to know what you’re looking for.
A track in Ardour 5.x can generate one of two signals. One is based on the data arriving at its inputs (we call this input monitoring), the other is based on pre-existing data stored on disk (playback). In Ardour 5.x the track can only generate one of these at any point in time. You can do various things to force it to always do one or the other (e.g. always monitor input). If Ardour never does input monitoring, and the transport is stopped, then the output of every track is definitionally silence.
Moving the playhead while stopped will never generate new output.
I’m using output signals as position of servo-motors instead of sound. These motors control the motion of machines called motion simulators. Each output corresponds to a degree of freedom.
You can see an example of that kind of machine here : https://www.youtube.com/watch?v=hQLF06rwzVE
I was expecting that behavior of Ardour, which makes perfect sense when used with sound.
I guess I’ll have to modify the code and recompile for that kind of special feature.
Anyway thanks for your quick reply Paul.
What kind of interface are you using? An actual audio interface? Or you have some other kind of interface with an ALSA driver that spoofs an audio interface?
I’m not clear from your description if you thought through the implications of what you are asking. You are essentially asking for the ability to output one sample value at a time, the equivalent of variable sample rate down to 0 Hz. That would definitely not be something useful for an audio interface, so you will find that you essentially cannot do what you are asking going through the audio processing chain. Something like the control voltage output of some synthesizers might be able to do it, but really you are looking for a more industrial type of D-A converter and software to drive it. Trying to use audio software for servo control is really stretching it beyond what you should expect to work.
I’m using VoiceMeeter, and VBan interface inside VoiceMeeter.
I wrote my own UDP client to receive audio packets sent from VBan, and then I sent position to my simulator via a specific interface.
I know that what I’m asking is unusual, and as you said it comes down to be able to play audio at at variable speed, down to 0 Hz. I don’t see why it would not be possible, as it seem to be possible to play at a slower rate than the usual 1x rate.
This is similar to “scrubbing”. The best that Ardour can do with scrubbing is to start at speed x and run for x time. The OSC code does actually try to do this, but it is probably not responsive enough for what you are doing as it expects the scrub encoder may keep turning and continues to play till a timeout stops it. The OSC code also only uses two speeds for scrubbing. Of course in alsa or jackd you dealing with a buffer full of audio at a time, not a sample at a time. So unless your frame rate is slow enough to match the buffer size, and probably the buffer size would need to be an exact match for what you are doing, things will be difficult in any software. It sounds like you would need purpose built sw for what you are doing.
I’m working at 48 KHz in Ardour, VoiceMeeter resamples at 16 Khz and sends UDP audio packets of 85 frames/6 channels at 188 Hz. I send motion data at this rate or at half this rate, i.e. 94 Hz after averaging those 85 frames, so it may work.
When I set the speed at 8 % it works and it can already be useful for me, but I could not find out yet what midi commands I should send to change playback speed (I have an incremental encoder available on my custom device that could be used for that, or maybe I could add a sort of pitch bend pot).
Generic midi does not have a transport speed command available. There also does not seem to be anyone working on extending generic midi in any way at this time. Perhaps MIDI 2.0 will give some push to this. (volunteers?)
When I’ll have more time I’ll set up a compiling environment and try to work on midi, as I’m doing custom Wired and wireless midi devices with Teensy.