Capture sound from jit.playlist
This is probably discussed before.... but still... dear cycling when you through a lot of new awesome features at us again with 9.1 It really makes me wonder... Why can't we still not capture sound from a jit.playlist? Not even with an adoutput~. ? This would be such a major upgrade to a lot of workflow in which you do quick patching and live coding stuff to create your artistic output.
Yess.... I know I can use jit.movie~ but thats a completely different object with a different approach to it. And if you advise me to use that instead why not autoload a jit.movie~ when i drag n drop a moviefile into a patcher? Or can we set that in some kind of preference?
Please consider an investment in this.
Thank you,
Mark
Another thing that is really different (missing) when using jit.movie~ instead of jit.playlist is the way audio is played back when reducing the playback rate to like 0.2. With jit.playlist there's is this nice sounding timestretch artefacts going on but with jit.movie none of that good stuff ;-(
I've pinged the ticket for the jit.playlist~ feature request with this thread.
And if you advise me to use that instead why not autoload a jit.movie~ when i drag n drop a moviefile into a patcher?
You can hold down the option key while dragging and you get some alternate behaviors, one of which is jit.movie, which might be easier to turn into a jit.movie~ since you just need to add the ~.
There are legal and infrastructural reasons that jit.movie~ is not an item in the popup list, but I'll make a ticket to explore adding that.
With jit.playlist there's is this nice sounding timestretch artefacts going on but with jit.movie none of that good stuff
Well if a jit.playlist~ is made from jit.movie~, the audio playback engine won't be changing. It sounds like what you really need is to use groove~ with timestretching enabled. If interested I'm happy to show a patch that syncs jit.movie to groove~, from there you could easily make a clipping that sits in your sidebar, ready for dropping into your patch. it could contain a dropfile that would load things appropriately.
In any case, this whole area could use some consideration for how to make more user friendly. I'll make a ticket and can discuss with the team.
Hi Rob,
Thx for your elaborate reply and explanation. And thx for pinging a ticket on this.
For me it's not about patching a system with jit.movie~ drag n drop while holding option from within Max. (BTW Option dragging from finder won't give me any menu in a patcher... just a copy in my filesystem of the file.;-)
Its also not about doing some funky stuff with groove~. (Although I would love to see your solution for that). I can do all off that I believe. I can also loopback sound via my soundcard and record that while capturing with jit.vcr for example.
It's really about being able to quickly drag and drop videofiles from any source (let's say Mac finder) into a patch and capture sound and video while having a real good visual insight in the video playlist and loops in it.
jit.playlist is just the perfect object but with this major shortcoming which I still dont understand. Why can't I capture the sound it sends to my selected system sounddevice ?
Or Why isn't it demuxing like jit.movie~ is doing?
Sorry... there's really 2 things im addressing here I guess. or 3 even haha
Anyway I think my timestretch example is probably a weird setting with my system audio settings... but with the exact same movie played back at 0.2 rate it sound completely different with playlist then jit.movie~ when dragging from 1. to 0.2.
I can share recordings if you want.
Mark
I totally understand the reasoning behind the feature request, and agree it would be useful. We are very interested in easing the friction in this space so I appreciate you sharing your thoughts.
jit.playlist is simply a wrapper around jit.movie and jit.movie plays audio through the system device, using native libraries (in the case of avf engine). The timestretching is handled by those system libraries and we have no control of that, short of disabling entirely. But the discrepancy in sound is due to that timestretching vs jit.movie~ which doesn't perform any timestretching when the movie rate is changed (it just changes in pitch).
Hi Rob,
Thx again for your answers!
For me it's not about the time stretching stuff... that was / is just a thing I noticed in using the different objects.
I understand that jit.movie (and family object) audio is handled by the system and not by msp. But is that the reason for it not being able to capture it? I also remember there was spigot~ (or something) to capture audio from the QuickTime engine. Very nifty object indeed. To bad its deprecated and not replaced by anything really.
So now we have to wait for a rewrite / or new playlist object based on the jit.movie~ (and mc.jit.movie~) ?
Or do you think it's worthwhile to try and make something work with v8 and jit.movie~?