Movie Runner Crossfader (sans iterators)

You should probably look at this a little more. It's working fairly buggy for me.

When you trigger a movie to change, the crossfade/dimmer thing doesn't happen, but it does happen at the end of the clip. With some flipping around it's easy to get it in some mode where reset doesn't work anymore. I may just not be using it as intended.

Trying to get this to work AOK, but ran into an unrelated stumbling block to do with yuvs colour space and another with the directory scanner and .mp4 extension videos.

Both of these problems are reproducible with the Directory Scanner that doesn't find movies of .mp4, although they can be successfully loaded using the Movie Importer.

The simplest workaround for the .mp4 problem was simply to reassign the file's extension from .mp4 file to .mov.

Still the same data, just a recognised file format for the Directory Scanner.

& that just leaves the yuvs problem that I found I got with some of the Sonic Youth .mov videos in my Movies folder.

Error message is

[19:49:21.142]   <ERROR> QCProvider_CoreVideo: Unable to find corresponding pixel format for type 'yuvs'

I have tried the NI YUV to RGB image filter, but it isn't applicable to the video image so that particular snag just doesn't seem readily resolvable.

Any ideas / solutions / workarounds, anyone?

BTW, once the scanned directory has digestible file types, the construct works OK up to the point when I begin to press the up or right arrow keys and then the audio is lost from the movie playing, albeit the case that the movie files do mix.

I think this is pretty interesting. Shall have to look into it even further. Thanks for sharing.

When I point the Directory Scanner to search for Movies in /System/Library/Compositions, then your composition works well, as it isn't being presented with any yuvs colour problems with the movie files in that folder. It also isn't being presented with any .mp4 files that have had an extension re-assignment to .mov.

Although the aforementioned extension re-assignment workaround / hack works reasonably well , I have found that one or two perfectly playable as .mp4 files won't take the re-assignment as well as some others.

I really love the idea, thanks for sharing the comp! If you don't mind, i'll create a CoGe player module from it :)

Hmm I wonder why this goes awry when I'm messing with it. I can easily get it so that the movie loader isn't fed a string when it "should be".

I don't mind at all, in fact I'd be honoured, I'm a big fan of CoGe

The duplicate code in the two movie players still bugs me though... the software engineer perfectionist in me I guess :P

Yeah, I tried to note in the composition that the controls were buggy.

It really should be considered at the moment as a 'proof of concept', or an 'engine' for mixing between two videos.

The keyboard shortcuts for skipping clips were designed for jump to before the crossfade so I could test the crossfade was working... in hindsight I can see how that is counter-intuitive, as you would expect it just crossfade from there...

Hmm... I had developed it for a plug and "play" type scenario. So you are indeed correct in all of your presumptions :)

not sure about the YUV problem :( I've not encountered it before specifically, although I have done the extension renaming workaround for other filetypes.

Never thought of using it for compositions... love that it works though!

The audio bug is very curious... wonder what causes it - and the up and right arrows were just for testing crossfade, as gtoledo mentioned above it's not really intuitive as a non-debug interface :P

Because it's based on a 'toggle' system rather than iterators, things will sometimes maintain state when you don't want them to.

More specifically, I wouldn't expect it in its current state to support (at all) rescanning directories whilst already playing (but it may work sometimes :P probably whether or not the right player was playing or where it was in the list)

The string parsing was actually a last minute hack; as I had previously been using it with a hardcoded list of movies from across different disks turned into a structure and then just fed in like that - so there was never a chance of it getting out of sync (I wanted to make sure it was going to work flawlessly in the setup I was putting it in)

If there's enough interest in this 2 player mixer, I'd probably be willing to spend a little more time on it polishing it up - at least looking at the 'next' song input and directory scan bugs...

Can anyone explain what a virtual macro is? Is it an external patch/plugin which is actually in fact an entire composition in itself, but 'passing' as a macro for the intent of the parent composition?

How do I create one? Would it be a viable fix for the duplicate code in this composition?

I guess worst case scenario I just make multiple compositions and import two of the same 'movie player' compositions into the 'movie mixer' master composition... Hmmm

It's possible to implement a toggle system, with a dissolve patch, so that every time you call up an index, you fade back and forth from source a to b, regardless of when you call up a new index. Everytime an index changes, you trigger an object that controls fade a->b over a given duration. This way, with the fade happening in the image chain, you can render to whatever shape you want, and have a perfect fade. You can extrapolate this principle to take advantage of all of the blend modes as well.

What bugs it out this setup when I test, is when I start flipping before fade time completes. What is the right key supposed to do? Whenever I trigger that, that movie bank (?) is frozen, and it won't return state. I've tried with a few different folders.

I'm sort of willfully not looking at the coding, and just using what I see on screen, and in the notes, to see if it makes sense as I use it. After I hit the right arrow, what am I supposed to do to get things to where movies are playing?

for the code asis:

whilst the 'live' movie is from player 1, pressing 'up' will jump to just before the crossfade would have started at the end of that clip

whilst the 'live' movie is from player 2, pressing 'right' will jump to just before the crossfade would have started at the end of that clip

pressing either key while that player is not 'live' will still make the queued clip 'jump' to be just before the end of the transition, and if that player is player '2' it will suddenly appear statically in front of player 1 (as it is not triggered to 'start' yet).

But again, you're right, from a human computer interaction perspective, the only interface the user should use are the inputs available via inspector, and then 'space to start' :)

The other keys are for testing where it will crossfade from given the current settings, and a different key for each player just made the code simpler at the time of writing.

I'm very intrigued by a single 'fader' element... I think I might have a bash at implementing that.

That's a nice idea for doing this task. Thanks for sharing. I like the javascript to split the structures and create the fades. I vote for a polished version.

Ps. Create a virtual macro under Editor > Add to Library. And yes, it is a comp, with ports published to root that (for me) gets saved in ~/Library/Graphics/Quartz Composer Patches, then shows up in the Patch Library, loadable as a patch (with rounded corners instead of square in the Editor window). Very handy... Re: duplicate code, I don't think it would make a difference?

i don't think i'm a noob, yet this is one those basic things that seems to have been missing. Great start, i'll probably massage it a bit - if so, i'll keep you guys posted. Please, go on :)