torch slug since 2006
just realized ewaller's Splits isnt in the timer software list. im not sure if he is updating it anymore, but yeah it is a timer and it works. https://github.com/wallerdev/Splits/downloads
SDA Forum
A timer, sorry. I should have been more specific. And no, I would probably put it up on the App Store for a buck or two. It is much more realistic that I would continue to work on it and develop it if it could be a potential source of (ever so slight) income.
I guess I should have Activity Monitor open the next time I stream? 2Ghz / 4GB is what I have.
I guess I should have Activity Monitor open the next time I stream? 2Ghz / 4GB is what I have.
They work great, but improvement is always nice (mostly "would be nice to have" things). Norichan for instance, could benefit from not crashing if the USB disconnects. EasyCapViewer does this. Vsync would be nice too. I know Nate is adamant about further work on it (and I don't blame him). It's nice that we have this option at all.
Kumari improvement is definitely at the top of my list. Like DJS said handling various sources à la other stream software would be fantastic. The way Kumari handles video, fps, and CPU seems far better than anything else. Would also be great if it didn't pile the frames and instead dropped them (I believe Nate said he would change that behavior).
As for timers, given that I use ShitSplit for game time, I'm basically covered. It would be nice if it was a cocoa app though instead of running it through the Python interpreter.
Kumari improvement is definitely at the top of my list. Like DJS said handling various sources à la other stream software would be fantastic. The way Kumari handles video, fps, and CPU seems far better than anything else. Would also be great if it didn't pile the frames and instead dropped them (I believe Nate said he would change that behavior).
As for timers, given that I use ShitSplit for game time, I'm basically covered. It would be nice if it was a cocoa app though instead of running it through the Python interpreter.
HELLO!
So yeah, I've got Qt 5 installed, and I'm thinking about what kind of data model I need here.
I thought I'd be sneaky and just save *everything*. Just keep a running log of every attempt, and then derive things like attempt count and best splits from that. But dangit, that quickly gets messy when splits get edited, reordered, things like that.
So I probably do just have to store landmark data for the run, and for each split, and update them as we go.
I really hate this because data modeling is hard to do well and this is a really annoying spot to get stuck on in developing this app.
I thought I'd be sneaky and just save *everything*. Just keep a running log of every attempt, and then derive things like attempt count and best splits from that. But dangit, that quickly gets messy when splits get edited, reordered, things like that.
So I probably do just have to store landmark data for the run, and for each split, and update them as we go.
I really hate this because data modeling is hard to do well and this is a really annoying spot to get stuck on in developing this app.
wish i could be of more help than just saying "the agile way is to not care about the model at first". especially if you believe that knowing what you don't want is knowing something.
it does work though in my experience ... yua still exists and does most of the things it needs to do now, and the only reason it got there was me doing it the wrong way over and over again until the right way came to me. you don't find the way - the way finds you. hopefully.
another idea might be to look at the source code of other people's implementations. if it's all crap then you can feel better about this being a long-term problem to solve. if someone already has an obvious (in retrospect) answer then you can just copy it and stop worrying about it.
it does work though in my experience ... yua still exists and does most of the things it needs to do now, and the only reason it got there was me doing it the wrong way over and over again until the right way came to me. you don't find the way - the way finds you. hopefully.
another idea might be to look at the source code of other people's implementations. if it's all crap then you can feel better about this being a long-term problem to solve. if someone already has an obvious (in retrospect) answer then you can just copy it and stop worrying about it.
HELLO!
Everyone else uses simple, flat text files...
... Yeah, this has helped, thanks. I'm just going to sqlite this sucker. I know all the cool kids hate SQL these days, but this data isn't huge, it isn't complicated, and it isn't nested. There's no reason SQL won't work, and the SQL framework will give me some structure to map this out and not get hung up.
Thanks,
... Yeah, this has helped, thanks. I'm just going to sqlite this sucker. I know all the cool kids hate SQL these days, but this data isn't huge, it isn't complicated, and it isn't nested. There's no reason SQL won't work, and the SQL framework will give me some structure to map this out and not get hung up.
Thanks,
Forgot to mention this before. The CamTwist developer regularly works on and releases beta builds of 3.0 here: http://camtwiststudio.com/beta/
He doesn't really say what's changed or fixed. 3.0 also has a major difference in that it doesn't support the legacy sequence grabber, but rather CoreMediaIO. As such, QTB, FMLE, and various other apps won't recognize it. Regardless, it's there for those who want to try it out.
Going along with this, someone is (was?) trying to create an effect for CT 3.0 for encoding/streaming. The source for that is here if anyone is interested: https://github.com/zakk4223/CTstreamOutput
He doesn't really say what's changed or fixed. 3.0 also has a major difference in that it doesn't support the legacy sequence grabber, but rather CoreMediaIO. As such, QTB, FMLE, and various other apps won't recognize it. Regardless, it's there for those who want to try it out.
Going along with this, someone is (was?) trying to create an effect for CT 3.0 for encoding/streaming. The source for that is here if anyone is interested: https://github.com/zakk4223/CTstreamOutput
Edit history:
presjpolk: 2013-06-28 08:13:12 am
presjpolk: 2013-06-28 08:09:02 am
presjpolk: 2013-06-28 08:08:40 am
presjpolk: 2013-06-28 08:01:58 am
presjpolk: 2013-06-28 07:55:31 am
presjpolk: 2013-06-28 07:50:10 am
presjpolk: 2013-06-28 07:41:25 am
presjpolk: 2013-06-28 07:24:49 am
HELLO!
Quicktime Broadcaster and Hashd don't get along.
I've got four viable options:
Take Kumari and hack it into a tool that will pipe a camera (CamTwist) out QTKit Capture sadly won't work for me since blasted Blackmagic hasn't released drivers for the new interface
(alternately, write an ffmpeg script to do same)
Find a way to get Quartz Composer and Blackmagic to get along, then just use Kumari to screencap the composition.
Get new hardware that's Windows compatible, use OBS on my dev Macbook Air, create some hacky VNC setup to let that get to my splits.
Get new hardware that's QC compatible, use Kumari as above. Elgato HD is apparently trash for recording but it might do the job for this? Don't know. Probably won't work. What then?New Hauppauge?
I've got four viable options:
Take Kumari and hack it into a tool that will pipe a camera (CamTwist) out QTKit Capture sadly won't work for me since blasted Blackmagic hasn't released drivers for the new interface
Get new hardware that's QC compatible, use Kumari as above. Elgato HD is apparently trash for recording but it might do the job for this? Don't know. Probably won't work. What then?
HELLO!
So I just flat-out asked @elgato on Twitter if the Video Capture HD supports QtKit. They told me no. I'm really impressed with that honesty, and it makes me think well of them (even if it's not what I need!)
Also, a new kink: I project QTKit is itself on the way out. It's clear that QTKit is going to be replaced by AVFoundation, as an effort to merge the iOS and MacOS interfaces.
So any further efforts toward QtKit are a waste of time.
Also, a new kink: I project QTKit is itself on the way out. It's clear that QTKit is going to be replaced by AVFoundation, as an effort to merge the iOS and MacOS interfaces.
So any further efforts toward QtKit are a waste of time.