> Le 11 sept. 2019 à 17:32, Lukas Degener <lukas.dege...@posteo.de> a écrit : > > Excerpts from Stéphane Letz's message of September 10, 2019 10:11 a. m.: >> >> >> But you could perfectly allocate a mydsp_poly object with control = >> false, so that to be able to control each voice individually with OSC >> messages. >> > > Yes, I think you mentioned this in some older post to this list. > If I understood this correctly all the voices would be always active, > which seems a bit wasteful, though that would probably not be a real > issue in my case. > What bothers me more is that I would have to do the voice selection in > my game code. While this could work, I don't like it very much. Also, > should I ever decide to do some more sophisticated voice > allocation/stealing like mydsp_poly does, this would probably be easier > to do "closer" to the actual dsp code. > > Nah, the more I look at it, the more I think I need something similar to > mydsp_poly, but not exactly the same. I *want* it to control the voices. > Just... differently. :) > Maybe I can get away with subclassing it.
Yes this is always a possibility. > >> >> >> Yes, PresetUI was a first try for that, this is the reason it is only >> used in ca-qt.cpp for now. But It should be usable in other contexts. > > It does in fact work out of the box. Though with my current code, I > cannot switch presets via OSC. I think the main issue here is that > PresetUI is a UI decorator. It is supposed to decorate *one* UI, not two > of them. I probably could write something like a composite ui (as in the > composite pattern). That would allow me to do something like > > DSP->buildUserInterface(PresetUI(CompsiteUI(&qtInterface, &oscInteface), > rcFilename)); > > I will play around with this idea a bit. OK, and if you develop something that could beneficiate the developer community, feel free to do a PR… ((-; > >> >> Is the video game running as a standalone application? >> >> it case it helps we have an architecture for Unity, see faust2unity > > I am not using any game engine atm. Maybe I will at some point, but > for now, doing it "from scratch" is just more fun. > >> >> Feel free to ask more help ! >> > > Will do. For instance: how do separate (G)UIs keep their respective > state synchronized? From tracing through the code, it seems to me that > some GUIs (e.g. QTUI) simply call GUI::updateAllGuis() in regular > intervals, but then again others (like the OSC stuff) do not. > > So I was wondering... if I have two (or more) separate UIs which each > having "observable" state, than at least one of them has to do something > like calling updateAllGuis(), or else it wouldn't work. Correct? > Yes GUI subclasses can use this GUI::updateAllGuis() states synchronization model. And yes one only has to do that. In practice GTKUI to QTUI call GUI::updateAllGuis() in their event loop or using timers. Stéphane _______________________________________________ Faudiostream-users mailing list Faudiostream-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/faudiostream-users
