> On Wed, 15 Oct 2025, Ladislav Laska wrote: > That makes a complete sense and would allow to decouple the device
Awesome we are aligned ;-) On Wed, Oct 15, 2025 at 11:48 AM Vesa-Pekka Palmu <[email protected]> wrote: > device limitations from the driver to the user, ie. max sample rate with > the selected amount of channels, max sample depth for non-streaming > devices. Ok, so let me think about it and get a small PoC working, so we can iterate on it together ;-) On Wed, Oct 15, 2025 at 11:48 AM Soeren Apel <[email protected]> wrote: > such an effort feels misguided simply because it would further increase the > complexity of libsigrok > while cementing its role in the architecture. While I totally understand what you mean, I feel that given the current state of the project, it is already cemented somehow. > Creating a new block that provides data to the sigrok pipeline would not > only be completely decoupled from all other blocks, it would also not > matter which language it's written in. That's where I'd like to go. This is the better approach indeed, but I usually prefer to build small evolutions of on top of well used legacy stuff. That's where immediate huge value is and I personally cannot embark myself in a long journey anyway. Besides, nothing stops us to have a packet based protocol that can be used via stdin/out or tcp or even mqtt if want to be super fancy. So, if you don't object loudly, i'll move forward and try something out. Cheers, -- Steve Schnepp _______________________________________________ sigrok-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sigrok-devel
