KillingFrenzy

I'm running the 1.6.2 versions of Max and Jitter on XP.

I'm noticing the generation of .xml files of my AVIs when I load them into a quicktime player. It appears to have something to do with spigot, based on the xml generated. This is maddening behaviour, because I'm parsing through 1000's of avi files and the generation of an additional 1000s of .xml files makes a horrifying cluttered mess.

I'm noticing the generation of .xml files of my AVIs when I load them into a quicktime player.  It appears to have something to do with spigot, based on the xml generated.  This is maddening behaviour, because I'm parsing through 1000's of avi files and the generation of an additional 1000s of .xml files makes a horrifying cluttered mess.
How do I turn this off?


generation-of-xml-files-because-of-spigot

The .xml files shouldn't be generated unless you have @soc set in 

jit.qt.movie (e.g. unless you are using spigot~). If you are using 

spigot~, you need these files. If you are not, turn it off!

Am 10.11.2006 um 17:22 schrieb Leo Mayberry:

> I'm running the 1.6.2 versions of Max and Jitter on XP.

> I'm noticing the generation of .xml files of my AVIs when I load 

> them into a quicktime player. It appears to have something to do 

> with spigot, based on the xml generated. This is maddening 

> behaviour, because I'm parsing through 1000's of avi files and the 

> generation of an additional 1000s of .xml files makes a horrifying 

The .xml files shouldn't be generated unless you have @soc set in  
jit.qt.movie (e.g. unless you are using spigot~). If you are using  
spigot~, you need these files. If you are not, turn it off!

>
> I'm running the 1.6.2 versions of Max and Jitter on XP.
>
> I'm noticing the generation of .xml files of my AVIs when I load  
> them into a quicktime player.  It appears to have something to do  
> with spigot, based on the xml generated.  This is maddening  
> behaviour, because I'm parsing through 1000's of avi files and the  
> generation of an additional 1000s of .xml files makes a horrifying  
> cluttered mess.
> How do I turn this off?


So, this means that if I was using a large number of files with audio that I'd end up with a gigantic duplicate cache of all the audio tracks?

Ecch! I just found 700megs of cached audio, so yes.

I don't suppose the .xml files could be stored in a single location as well? That way the necessary clutter would be in one place. For various reasons I really don't want anything but content files in my content folders.

So, this means that if I was using a large number of files with audio that I'd end up with a gigantic duplicate cache of all the audio tracks?
Ecch! I just found 700megs of cached audio, so yes.
I don't suppose the .xml files could be stored in a single location as well?  That way the necessary clutter would be in one place.  For various reasons I really don't want anything but content files in my content folders.


Nope, not at this time, but you can send the following message to 

Where N is the preferred size of the cache in megabytes. -1 means 

unlimited. You're still going to get your XML files, though.

Am 10.11.2006 um 19:13 schrieb Leo Mayberry:

> So, this means that if I was using a large number of files with 

> audio that I'd end up with a gigantic duplicate cache of all the 

> Ecch! I just found 700megs of cached audio, so yes.

> I don't suppose the .xml files could be stored in a single location 

> as well? That way the necessary clutter would be in one place. 

> For various reasons I really don't want anything but content files 

Nope, not at this time, but you can send the following message to  
jitter:

Where N is the preferred size of the cache in megabytes. -1 means  
unlimited. You're still going to get your XML files, though.

>
> So, this means that if I was using a large number of files with  
> audio that I'd end up with a gigantic duplicate cache of all the  
> audio tracks?
> Ecch! I just found 700megs of cached audio, so yes.
> I don't suppose the .xml files could be stored in a single location  
> as well?  That way the necessary clutter would be in one place.   
> For various reasons I really don't want anything but content files  
> in my content folders.


I think my solution is just to segregate my files that have audio and use a seperate player/file loader for them that is more particular about filetypes that show up in the menu. Though a nice option (if possible) in the future would be the ability to have the .xml files generate in a single location.

The cachesize limitation is nice.
I think my solution is just to segregate my files that have audio and use a seperate player/file loader for them that is more particular about filetypes that show up in the menu.  Though a nice option (if possible) in the future would be the ability to have the .xml files generate in a single location.


It's not that it's impossible. But it's a lot more convenient for the 

XML file for file X to sit next to X. If you use Ableton Live, for 

instance, or (back in the day) Prosoniq SonicWORX, you'll know that 

these programs also place analysis files next the the audio files 

they work with. This helps with one problem in particular.

Say you have 3 movies on your HD, all named test.mov. Obviously, they 

can't all live in the same directory. So, it's safe to create 3 

test.mov.xml files, one for each instance. If all the XMLs were in 

the same directory, only one test.mov.xml could exist, limiting the 

ability of spigot~ to simulataneously work with all 3 files.

It's an edge case, but that's the principle reason why this decision 

was made. It's also a nice, clear way to know if the file has been 

looked at by spigot~. In any case, I don't anticipate this changing. 

It might be possible for de-cached items to have their XML files 

deleted, but that struck me as unnecessary at the time, and I don't 

Am 14.11.2006 um 11:52 schrieb Leo Mayberry:

> Though a nice option (if possible) in the future would be the 

> ability to have the .xml files generate in a single location.

It's not that it's impossible. But it's a lot more convenient for the  
XML file for file X to sit next to X. If you use Ableton Live, for  
instance, or (back in the day) Prosoniq SonicWORX, you'll know that  
these programs also place analysis files next the the audio files  
they work with. This helps with one problem in particular.

Say you have 3 movies on your HD, all named test.mov. Obviously, they  
can't all live in the same directory. So, it's safe to create 3  
test.mov.xml files, one for each instance. If all the XMLs were in  
the same directory, only one test.mov.xml could exist, limiting the  
ability of spigot~ to simulataneously work with all 3 files.

It's an edge case, but that's the principle reason why this decision  
was made. It's also a nice, clear way to know if the file has been  
looked at by spigot~. In any case, I don't anticipate this changing.  
It might be possible for de-cached items to have their XML files  
deleted, but that struck me as unnecessary at the time, and I don't  
plan to add it in the near future.

> Though a nice option (if possible) in the future would be the  
> ability to have the .xml files generate in a single location.


Generation of .xml files because of ~spigot?