Hey Pierre, You probably know already that there is an openframeworks-ofelia package „ofxofelia“?! Maybe it helps you with your openframework plans
All the best, Jakob > Am 08.10.2019 um 15:23 schrieb pie...@314r.net: > > Le 2019-10-07 18:27, Christof Ressi a écrit : >>> I think this is not exactly true : >> ha, I just had a look at the code and you're right! Here's the offending >> line: >> sys_setmiditimediff(0, 1e-6 * sys_schedadvance); >> I think it should be: >> sys_setmiditimediff(0, sched_useaudio != SCHED_AUDIO_NONE ? 1e-6 * >> sys_schedadvance : 0); >> There's no need to delay MIDI if DSP is off. I'll make a PR. > > > thanks to have a look into this ! > I've edited m_sched.c accordingly (lines 515 and 555) but with no luck : > latency vary again with delay parameter > looking forward your PR =) > > >> anyway, MIDI latency is certainly not the problem here, it rather >> seems like Pd/GEM is running slowly. If Pd blocks, then incoming MIDI >> will have to wait as well. > > > yep true, I also dont think that it is midi code which is slowing down Pd, > but the thing is midi is delayed and this is what I want to avoid > > >> Unfortunately, I can't help much with GEM, >> but there are other people around on the list who might have something >> to say. > > > Yeah I hope I'm not the only one having this kind of consideration =) > > >> If you have a really heavy Pd GUI, you can try to move it to >> another Pd process and communicate with the video process with >> [netsend]. > > yep, I can do somes tests with nogui and/or another pd instance > > >> Alternatively, you might give Ofelia a try and see if you >> get better graphics performance. > > > I'm currently learning openframeworks, mainly because of this latency problems > > anyway, thx for your help > > > Pierre > > > >> Christof >>> Gesendet: Montag, 07. Oktober 2019 um 17:33 Uhr >>> Von: pie...@314r.net >>> An: Pd-List <pd-list@lists.iem.at> >>> Betreff: Re: [PD] [GEM] advices about midi latency ? >>> Hi Christof, >>> Le 2019-10-07 12:28, Christof Ressi a écrit : >>> >> reduce pd audio buffer to 3 >>> > >>> > generally, you shouldn't run audio in the video process (unless you >>> > really need it). if you don't use audio (DSP is off), there is no need >>> > for latency and therefore the buffer size doesn't have any effect (in >>> > fact, a different scheduling mechanism is used where the message >>> > system is ticked every ~1ms). This means you should get MIDI input as >>> > fast as possible with low jitter. So turn DSP off in your video patch! >>> Mmmm, >>> I think this is not exactly true : >>> adjusting audio delay, while dsp is *OFF* does something on midi latency >>> (I'm on debian/ubuntu, dont know for other OS's), >>> if you have an midi interface you can try the attached patch. >>> (you will have to link, with a real midi cable, the input of the midi >>> interface with the output for the patch to work) >>> >> all I want is to optimize midi latency >>> > >>> > 1 frame at 60 fps is 16 ms. MIDI latency shouldn't be your bottleneck. >>> yep, if I use "pd -sleepgrain 0.1 -audiobuf 3" I get a midi latency >>> around 4ms >>> > If you really want to minimize graphics output latency, then you would >>> > need to run at a higher framerate, assuming your hardware (monitor, >>> > projector) is capable. But what is your actual problem? Is it about >>> > your video output *noticeably* lagging behind your MIDI input? >>> I allways try to run the gemwindow around 60fps (depends on the output >>> screen refresh rate) >>> what I notice is that when I open my big gem patches with 3d objects, >>> textures, shaders etc, the lag is around 70ms. >>> and so I must adjust my 'delay line controler'(1) accordingly to keep >>> things in sync >>> (1)https://www.thomann.de/fr/the_tracks_dl_2918_delay_line_controller.htm >>> Once the [gemwindow] is created >>> - 'nvidia-settings' tells that GPU utilization is around 30%, >>> - 'htop' tells the CPU utilization is around 25% >>> But yes, even if my CPU and GPU dont seems to be harassed, my visual >>> output lag (~70ms)... >>> and I'm trying to understand why and where it happen. >>> >> - tcltk could also be a problem because I have big patches >>> > >>> > the Pd GUI runs in another process. >>> ok but what I experiment is that if I select a lot of object in my big >>> gem patch and move them, >>> the midi lag, as measured ans shown in the attached patch, go as high as >>> 200ms and higher... >>> So my conclusion is that in some way, the gui refresh influence the >>> whole process (and not just its own thread)... >>> Sorry if I'm not as clear as needed here, >>> I have done somes investigations : >>> - profiled [gemhead] render chains with timers (inside pd) >>> - analysed my pd/Gem patch with the nvidia-settings app and from the >>> nvidia nsight graphic debugger >>> - profiled midi lag with 'pd' and 'alsa-midi-latency-test' >>> i got somes results, but I think it can be way better... >>> In others words, what I want to do is somehow 'simple' : >>> draw a rectangle in sync with a short hi-hat coming from an electribe >>> (a short hi-hat is ~15ms long, a latency of ~20ms is acceptable) >>> If you have any ideas with that, I'll be very happy =) >>> Pierre >>> > >>> > Christof >>> > >>> >> Gesendet: Montag, 07. Oktober 2019 um 11:38 Uhr >>> >> Von: pie...@314r.net >>> >> An: Pd-List <pd-list@lists.iem.at> >>> >> Betreff: [PD] [GEM] advices about midi latency ? >>> >> >>> >> Hello all, >>> >> somes questions here about midi process optimization : >>> >> >>> >> the midi setup : >>> >> a korg electribe send midi message (noteon and controlchanges) to an >>> >> usb soundcard (umc204hd) connect by USB to >>> >> puredata/gem to finally draw things on screen (3d objects, videos >>> >> textures, shaders etc) (nvidia hardware and drivers) >>> >> >>> >> all I want is to optimize midi latency and be able to draw things as >>> >> fast as possible (considering this hardware) >>> >> ie reduce the time between the midi event and the generated graphics >>> >> >>> >> what I've done : >>> >> reduce pd audio buffer to 3 >>> >> use a 'delay line controler' to delay audio (something like 60ms is >>> >> needed) and so retreive an 'good' A/V sync >>> >> >>> >> I know that : >>> >> - double buffering add latency (and solve flickering) >>> >> - somes videoprojectors add latency due to an internal video buffer >>> >> - the more I can draw frames/second the more I can draw small events >>> >> on >>> >> screen (nyquist) >>> >> - tcltk could also be a problem because I have big patches >>> >> - when I measure midi lag by looping a midi message to and from the >>> >> usb >>> >> soundcard I get around 2ms, which is very good ! (tested with pd and >>> >> also with alsa-midi-latency-test) >>> >> >>> >> any experience or advice on theses questions ? >>> >> what are yours best setup/experiences to acheive really fast sync ? >>> >> thanks you all >>> >> >>> >> >>> >> Pierre >>> >> >>> >> >>> >> >>> >> _______________________________________________ >>> >> Pd-list@lists.iem.at mailing list >>> >> UNSUBSCRIBE and account-management -> >>> >> https://lists.puredata.info/listinfo/pd-list >>> >> >>> > >>> > >>> > >>> > _______________________________________________ >>> > Pd-list@lists.iem.at mailing list >>> > UNSUBSCRIBE and account-management -> >>> > https://lists.puredata.info/listinfo/pd-list >>> _______________________________________________ >>> Pd-list@lists.iem.at mailing list >>> UNSUBSCRIBE and account-management -> >>> https://lists.puredata.info/listinfo/pd-list > > > > _______________________________________________ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list