Forum Replies Created

Page 11 of 27
  • Brett Sherman

    December 24, 2013 at 12:48 am in reply to: Things could get… interesting…

    [Jeremy Garchow]
    In your sparse bundles, are those usually self contained jobs? Or do you have multiple jobs in each bundle?”

    Actually multiple bundles per job. Jobs typically use between 1 and 7 bundles though I have one with I think 50. And the same bundle may be used for many different jobs which have their own unique set of bundles they need. If you could look at a diagram of sparse bundles to jobs, it would look like a web. I think that’s where the complication comes in.

    I’m trying to wrap my head around this. So when FCP X 10.1 creates a new library does it copy media from the old event file into the new library event? I thought this was the case.

    Say I have two Jobs A & B that both use event X. They are in separate bundles. First I mount Job A and event X and convert them to a library. Then I Consolidate the event X to the NAS server.

    Can I then convert Job B without event X mounted and then drag event X from Library A into Library B? Will FCP X understand this as the same event that has gone missing in Job B after I’ve already made a library out of it?

  • Brett Sherman

    December 23, 2013 at 3:32 am in reply to: Things could get… interesting…

    [Jeremy Garchow] “No, I am sorry. I am not griping to you or to anyone. I apologize.”

    No need to apologize, I was really being a bit facetious and took no offense. I hope I didn’t offend you either. I appreciate the info. Ultimately the problem with the transition is that neither of the methods recommended works for me.

    Apples method – Open everything and it will create gigantic libraries for you. I’d have to open around 200 sparse bundles and since I’m using managed media with projects that span multiple drives I’m not even sure how it would attempt to handle it.

    Event Manager X method – I could do this, but it would probably require double the hard drive space (at least). Why? Because I tend to use the same events in multiple projects. If I convert each project one by one it’s going to create new media for the same event over and over again.

    My solution – which I need to test and is on theoretical at this point. Is to make all my events have unmanaged media BEFORE I transition. This way FCP X doesn’t even attempt to move media files around. Basically I take all the media out of the “Original Media” folder in the event file (in a sparse bundle). Move it to a folder on my NAS server. Relink the files in 10.0.9. Do this for all 150 or so events I have that are managed. Then upgrade to 10.1. Now I can update project by project, because doing so will only create duplicates of the event file and not the media itself.

    The advantage of this method is that I shift all my media to external media, which it’s going to need to be going forward. And there is no rush updating projects. I can do them as needed in the future. But still have access to the events for current projects. It’s also backward compatible to 10.0.9. I just leave my projects and events in place with linked media instead of managed media. So I can keep plugging away in 10.0.9 until I’ve got them all done.

    Regardless, this is going to be time consuming. And thank god I’ve only been using FCP X for a year. Ironically, it may slow down my purchasing of a Mac Pro. I can’t buy it until I’m done all this.

  • Brett Sherman

    December 21, 2013 at 6:44 pm in reply to: What in the name of Jupiter?

    I store things in sparse bundles. For the main project, I create a folder called “bundles to launch” then put shortcuts in that for all the bundles I need to launch for that project. Opening the folder automatically launches the bundles and all events I need for the given project. So I might use 10 bundles for a project. But there is so much overlap, I might use bundle A & B in project C, where project D uses bundle A and X, but not B, and project E uses bundle B and Y but not bundle A. So I can’t update project C without also updating project D & E at the same time. Now multiply that scenario times 50 and you see the dilemma I’m facing.

    The problem is that I can’t update project by project since that will modify the event for one project but not the others.

  • Brett Sherman

    December 21, 2013 at 3:33 pm in reply to: Things could get… interesting…

    I think maybe your griping about my opinion here because I seem to be one of the few here not completely behind the new library structure. Let me clarify my position here so it’s not misrepresented.

    I’m not against the library structure. I see future efficiencies it will create. But these are created at the expense of more manual management of files, at least for me.

    I’d be 100% behind it if they had done three things differently:

    1. Allowed you to use material from a different library without having to copy media files or event files.
    2. Allowed you to also externally locate render and transcode files
    3. In the conversion to libraries allowed you to convert from managed files to external files leaving all media in place.

    It makes using events across multiple libraries inconvenient. Since this is what I do all the time it is an inconvenience. I basically have to create multiple versions of the same event. This means if I favorite part of a clip in an event for one library it won’t show up in another library that I use the same event. Sometimes that’s okay, sometimes it makes thing inefficient. I have to go favorite the same stuff again. Now if I’m super organized I can copy the event that I’ve modified to the other library. But quite frankly, I don’t have a staff like you do. I have to rely on my memory about which event I last modified and I don’t have time for this kind of manual management. I wish a did, but reality intervenes.

    When moving libraries around, you’ll have to delete all the render files and transcodes to get them to a size that can be portable – again manual management. I’m hoping for a utility that will duplicate and backup a library and strip out all the render, thumbnail and transcode files automatically.

    Then finally, the conversion to the new library system I don’t think is particularly well-implemented. As I’ve said in other posts, they should have allowed you to convert events and projects from managed to external media leaving all existing media in place so you don’t have to create these new gigantic library files that waste hard disk space and take a lot of time and risk. But maybe I’m not completely understanding how it works.

    What I can’t quite understand is why they made it impossible to utilize material from another library without copying it into your current library. I’m sure there is a reason for this, but it would make my life a lot easier if I could.

  • Brett Sherman

    December 21, 2013 at 2:59 pm in reply to: A step backwards

    [Mitch Ives] “If the price of making this a better collaborative tool for them is me wasting a day updating projects and manually relinking files… I can live with that.”

    Lucky you. I’ve got a week at least. They could have made the transition easier. Rather than converting managed files to managed files they could have simply turned the managed media into external media leaving it in place and created new libraries and events linked to the original location.

    Now it seems that Apple is now listening to the large facilities…at the expense of us small fries.

    Although I echo your sentiments, if this creates a larger market share I’m all behind it. I just think the transition was simply not well thought out.

  • Brett Sherman

    December 20, 2013 at 4:32 pm in reply to: Not crazy about the new media management structure

    Going forward then who would bother with managed media.

    Does external media still need that goofy alias file that the current version requires? How do you convert from managed media to external media? Does it require relinking? Also, does the Library remember the folder you want to import files to? If not, I see a lot of misplaced files in the future. And why can’t you externally locate render/transcode files to make the library file a nice small file that can be passed around? Seems like they should have just gone with the FCP 7 file structure which basically they’re emulating now without the capability choosing where to locate render/transcode/thumbnail files.

    But the bottom line is I see how I can work with it in the future. Basically I’ll make new events for every project I start that will go in it’s own library, even if that event is 2 years old. So I’ll end up with multiple copies of basically the same event which isn’t that big of deal. Maybe I’ll have a single library of events for each drive from which to pull from.

    The real problem for me is getting to that point from where I am right now.

  • Brett Sherman

    December 20, 2013 at 2:34 pm in reply to: What in the name of Jupiter?

    [Charlie Austin] “. I’m not sure people understand how utterly painless this transition is.”

    Hmm. I don’t think you quite understand how I’m working. In a typical post facility you work on one project for a finite amount of time with all footage for that project contained in one location. And they rarely have to access that project again years in the future.

    I’m an institutional video producer. This means I have multiple drives full of material, probably 200 or so events that I continually use for years. These events are used in any of the 100 or so projects I have. So projects have media that are pulled from up to 10 drives. One event may be used in 10 or so different projects. So I can’t update one project at a time. I’d have to open about 250 sparse bundles (Does OS X even let you open that many logical drives?) and let FCP X churn away for a couple days and hope it doesn’t crash and does everything correctly. Not to mention it’s probably going to double the amount of hard disk space required. That’s just not going to work.

    The ONLY way forward I see is to convert all my managed media to external media BEFORE I upgrade to the new version of FCP X. Which I haven’t exactly figured out how to do yet. Like I said this is going to be enormously complicated and time consuming. If someone can tell me a better way I’m open to it – but I’m not seeing another way forward.

  • Brett Sherman

    December 20, 2013 at 2:06 pm in reply to: Not crazy about the new media management structure

    Yeah I think I’m going to have to move to external media storage. Although I will add that was ALWAYS possible with the previous structure. The only difference I see is that you can set a location during capture which is a little more convenient.

    But now I have about 150 events I’m going to have to turn into external media. What is this about a week of work?

    Can somebody clarify something for me. The way I see it, it is impossible to have a project with media that spans multiple drives with managed media. If so, is anyone really going to manage media anymore? What happens if your project fills up a drive are you SOL and forced to switch to unmanaged media?

    As much as people like the library structure, I’m not sure this was particularly well thought out.

  • Brett Sherman

    December 19, 2013 at 9:41 pm in reply to: er, is that it?

    [Andy Field] “the number one reason we avoid FCPX is audio mixing and key framing….I can’t see how editors prefer rubber banding and manually adding keyframes when you can simply created them in real time with a software mixer to easily fineness ducking music and nat sound….weaving a nice mix under narration without stopping everything and breaking out the pen tool.

    I’ ve never liked live mixing. Especially software interface mixing. Maybe I’m not good at it, or maybe people think they are better at it than they actually are. 🙂 I find FCP X’s rubber banding exceptionally fast and easy. The realtime waveform feedback is a boon too. And you don’t need the pen tool, just Option-click. Also Ctrl +/- to adjust overall clip level. Now if there were a control surface with faders, I might give it a shot. But still it requires you to predict the future.

  • Brett Sherman

    December 19, 2013 at 9:03 pm in reply to: What in the name of Jupiter?

    I’m staying too. Unless, getting a new computer requires me to update or there really is a significant speed advantage. The process of transitioning to the new file system is going to be very painful for me.

    My one hope is that the library structure was necessary for future sharing capabilities. In that the structure may keep all the different versions users are working on concurrently contained. But my hopes have been dashed before.

Page 11 of 27

We use anonymous cookies to give you the best experience we can.
Our Privacy policy | GDPR Policy