00:49 <_whitenotifier-4> [glasgow] whitequark created branch nagle2 - https://github.com/GlasgowEmbedded/glasgow

00:50 <_whitenotifier-4> [glasgow] whitequark deleted branch nagle2 - https://github.com/GlasgowEmbedded/glasgow

00:51 <_whitenotifier-4> [glasgow] whitequark opened pull request #948: Flush IN FIFO once per microframe - https://github.com/GlasgowEmbedded/glasgow/pull/948

00:55 <_whitenotifier-4> [glasgow] whitequark synchronize pull request #948: Flush IN FIFO once per microframe - https://github.com/GlasgowEmbedded/glasgow/pull/948

00:59 <_whitenotifier-4> [glasgow] whitequark commented on issue #794: Get rid of explicit flush / autoflush as currently implemented - https://github.com/GlasgowEmbedded/glasgow/issues/794#issuecomment-3064449196

00:59 <whitequark[cis]> if you have a throughput- or latency-sensitive applet, please test out this PR: https://github.com/GlasgowEmbedded/glasgow/pull/948

10:48 <miek__[m]> Catherine: here's the fixture file https://gist.github.com/miek/cdbcbd1b4ff3f65f271f52d4257376ee and I also had to make a little patch to let it run fully

10:51 <miek__[m]> one problem i'm seeing is that the i2c reads are often failing, not being acked. i have to try a few times to get the applet to work. are there any known issues before i debug some more?

10:52 <miek__[m]> and yeah, i'm fine with being set as code owner for that applet

15:19 <galibert[m]> is there an example of using glasgow script somewhere?

15:23 <Attie[m]> https://glasgow-embedded.org/latest/use/repl-script.html

21:30 <galibert[m]> fuck, mido seems unusable in an async context. In fact there doesn't seem to be anything sane in python doing async midi

21:43 <zyp[m]> what do you need to do?

21:44 <galibert[m]> I have a glasgow applet to capture audio output (i2s-related) on my mu100b. I want to start the capture, send some midi messages, wait a bit, send another midi message, stop the capture, work with the result

21:44 <galibert[m]> I've patched the rom of the mu100b to do amusing things with sysexes

21:45 <zyp[m]> are the blocking midi send calls slow enough that it's an issue?

21:46 <galibert[m]> It may not be an issue, but I don't know how to have the capture loop running "in parallel"

21:47 <galibert[m]> I must say (cooperative) threading in python is really atrociously documented

21:49 <galibert[m]> four samples at 44100

21:49 <zyp[m]> an easy way to turn blocking calls async is to use run_in_executor() to have them called on a background thread, ref. https://docs.python.org/3/library/asyncio-eventloop.html#asyncio.loop.run_in_executor

21:49 <galibert[m]> enough buffering to have blocing calls elsewhere, but even for that I have no idea on how to do it

21:51 <galibert[m]> ok, how do I start my mu_iface.run() so that it runs while I'm doing the run_in_executor stuff?

21:52 <zyp[m]> task groups: https://docs.python.org/3/library/asyncio-task.html#task-groups

21:55 <galibert[m]> ok, sounds like you've given me all the required pieces. Now time to try them

21:57 <zyp[m]> if you needed to do a full blocking task, like a loop waiting for midi messages, it would probably be easier to just spin up a dedicated thread for it and have it put all the messages in an asyncio queue

21:58 <galibert[m]> I don't tend to need read when capturing audio, so that should be ok

21:58 <zyp[m]> yeah, I just figured it was worth mentioning, since it's another common piece of blocking/async interop

21:59 <galibert[m]> :-)

22:07 <galibert[m]> ohhh, looks like I may have something that works

22:09 <galibert[m]> much thanks

22:11 <galibert[m]> yep, confirmed, it works