Clojurians Log v2

Here we go! It's a new series!

Interesting topic! Not really much to say yet, but excited to see where this goes. I haven't done any video editing, so all of my guesses on how you might approach this are entirely speculative shots in the dark. I'll have to listen again before the next one and make a plan. See how far off the mark I am 😋

Like most of these situated problems, there's a bunch to do outside of the core problem. There's querying the DB, downloading things, uploading things, sequencing things. Oh the problems! 😁

But, https://clojurians.slack.com/archives/C8NUSGWG6/p1701380689360989 with @smith.adriane. He's the author of https://github.com/phronmophobic/clj-media. Lots of audio and video fun to be had!

@jason.bullers Let me know what you come up with!

Kind of hand wavy, but in my mind, the solution probably needs to be somewhat metadata centric because of the potentially large clip sizes. What's interesting about that is there's probably a lot of cool data transformation and merging just from what you described the metadata could look like. Once you calculate the clips and their ordering or subsets, I suppose there would be a bunch more metadata processing specific to the video encoding, and then some streaming APIs to read and combine the files (unless you have a mountain of memory available) Haven't thought too deeply on it yet, so maybe oversimplified or way off the mark

That pretty much describes what's been on my mind! Every part of the process is big and slow, so a pure data representation becomes extremely helpful.

Organizing the work vs doing the work, so to speak.

I'm thinking about a similar problem to Sportify! (I added the exclamation mark for fun), so I'll be quite interested in this series. My case is about a client/server game. Eventually I realized that it is mostly about I/O as well. The core of the client side is a state machine. The I/O is asynchronous. So state needs to use some sort of STM. At first I thought I'd have the async I/O threads directly update an atom, to save data and update the state. But the result smells something like OO. I might switch to using channels and a dedicated thread where I can describe the state machine in functional code (more understandable). But that does add complication. I'll be curious about the paths you take!

@john.t.richardson.dev I love those kinds of problems! I like the direction you're describing. I've done a lot of work with stateful problems, because I've had a lot of situations where I needed to create something that's live and reacting to events. I would definitely recommend making a pure model of the state and the operations on that state. You can unit test the heck out of it and keeps you focused on representation. That also keeps all the I/O as a "plumbing" problem for getting the event from its source and routed to the keeper of the state. I have also have used a thread that loops on a core.async channel for that state keeper. (Something like an Erlang process.)

What's cool is that you can change your approach to I/O and it doesn't end up being a big deal. The pure model is where all of the action is.

I have a library for creating a "worker" (which is similar to a Erlang process) that just uses core.async channels for communication. That's one approach. I often need it because I have to do I/O in response to state changes, so I need a thread. I have a way of connecting these workers into a pipeline for cascading changes. The workers all use pure logic, but the pipeline is stateful for efficiency of live operation. @nate keeps bugging me to release the library.

I’ll listen soon, wanted to share this project ( I think it started with Pixar ) … lots of c++ though. https://github.com/AcademySoftwareFoundation/OpenTimelineIO

> I would definitely recommend making a pure model of the state and the operations on that state. I hear you! My model has the I/O all happening on the other side of an architectural boundaries (constructing boundaries in Clojure is another thing I'm learning about, but sort of off topic for here). As you say, it's nice to be able to unit test the pure state machine. And it will be nicer to read once it actually behaves functionally.

Oh, and I just noticed that you also added the bang to Sportify! I guess that really came across in the audio!

Hahahaha. We try to keep these dry programming episodes light.

@bocaj Wow! That's a cool project! Having an open standard for editing timelines is a huge win for the industry.

@john.t.richardson.dev Nate had to keep me from just making the whole notes "Sportify! Sportify! Sportify! ..." 😉