Creative Communities of the World Forums

The peer to peer support community for media production professionals.

Activity Forums Creative Community Conversations PluralEyes for FCPX demo video

  • Bruce Sharpe

    December 15, 2011 at 5:48 pm

    The dual-system audio project in the demo was perhaps overly simplistic (in an effort to be clear). A more representative example of what PluralEyes is asked to do looks like this:

    That project took about 40 seconds to sync.

    As for the general question of what does PluralEyes offer beyond the built-in sync, the best answer that I can give is that we have had many FCP X users begging us to have PluralEyes work with it. And, as always, our products have fully functional, free, 30-day trials so that anyone can try them out and judge for themselves if they are worth the purchase.

    Bruce

    Bruce Sharpe
    Singular Software Inc.
    http://www.singularsoftware.com

  • Jeremy Garchow

    December 15, 2011 at 6:40 pm

    [Aindreas Gallagher] “people are positing that the actual underlying database itself could be fundamentally flawed, I mean sure, maybe we could be looking at stuff that is super easy to fix, alternatively however, the number of springs falling out of this thing could indicate deep, extremely hard to rectify, basic structural errors in Apple’s approach.”

    I don’t buy that it’s deeply flawed, but that’s just me. There’s some repetition being written that isn’t addressed. To me, it feels non-optimized. These are baby steps (right or wrong).

    [Aindreas Gallagher] “what confidence do we realistically have that Apple have anything like the wherewithal to remedy this?”

    We can only guess. My guess-thoughts are that multicam is coming, and with that will come media tracking by container (such as multiclips with FCP7). Let’s just say that Apple “missed” the bloat bug. When writing the multicam infrastructure, it will become very obvious very quickly that these containers can cause a bit of bloat. Add some markers that get repeatedly written consistently, and then not flushed, and the XML explodes. These bloat problems that have been demonstrated is to take a really long compound clip (45 minutes) and then cut it up, causing all the repeat information. In essence, this is what a multiclip is going to be. If Apple doesn’t realize or see this, then yes, there’s a fundamental problem with the development team. My feeling is that they realize it, and will fix it. Deeply flawed I don’t buy, but some areas that aren’t quite working, absolutely. From what I have heard, the FCPXML information is extremely sparse at the moment. This is telling in that it’s just not quite there yet. It does not mean that it won’t mature or get additional capability.

    I was trying to test an entire FCP7 project XML to PPro CS5.5 import yesterday. The FCP project is pretty big. 2000 elements, 200 something sequences, yadda yadda. The project file is 65MBs, the resultant XML representation was 175MBs, 2x+ the size. It happens, it’s just how the application deals with the bloat that is the problem. If it grinds everything to a halt, that’s not good.

    [Aindreas Gallagher] “I would stand here until doomsday bashing Apple – God knows – but on a certain genuine level I’m beginning to wonder if they still actually know what they are doing with this kind of software – if they actually still have at all the necessary skill set or basic competence to internally produce this class of software?”

    I don’t know for sure. I can see how confidence in them might be waning. They say they are interested, I can only take them at their work until they prove otherwise. I’m willing to give them a mulligan or two as this program is all new. As far as iTunes goes, I have never had a problem with it, and it tracks a crap load of little information blobs. It’s been reliable for me, but maybe not for you. I don’t really expect a lot from iTunes except to not lose my music/apps/whatever and play tunes. It seems to fit the bill.

    Jeremy

  • Aindreas Gallagher

    December 15, 2011 at 7:28 pm

    yep, that’s totally reasonable, I don’t really have anything against itunes myself, but you do read a fair amount of bitching about the quality of the coding in it, mostly the windows version though – still – even gruber bitches about itunes in that way.

    As you say though – they haven’t had much of a shot at rectifying this stuff yet. God knows we really, really are the beta testers on this thing.
    The next two .1 updates should pretty conclusively indicate whether they’re actually up for this kind of thing anymore.

    http://www.ogallchoir.net
    promo producer/editor.grading/motion graphics

  • Jeremy Garchow

    December 15, 2011 at 7:34 pm

    [Aindreas Gallagher] “The next two .1 updates should pretty conclusively indicate whether they’re actually up for this kind of thing anymore.”

    Whole heartedly agree.

  • Matthew Celia

    December 15, 2011 at 8:18 pm

    Thanks Bruce! yes, much more impressive to see that – also impressive to hear it only took 40 seconds. I will agree that FCPX built-in sync is not quite as fast. Can certainly see a valid use for such a tool on more complex projects.

    —————-
    FCP Guru
    http://www.fcpguru.com

  • Andreas Kiel

    December 16, 2011 at 11:50 am

    Yes – Bruce really know how to do things like that!

    Here some other point mentioned above

    Jeremy wrote:

    From what I have heard, the FCPXML information is extremely sparse at the moment. This is telling in that it’s just not quite there yet. It does not mean that it won’t mature or get additional capability.

    I was trying to test an entire FCP7 project XML to PPro CS5.5 import yesterday. The FCP project is pretty big. 2000 elements, 200 something sequences, yadda yadda. The project file is 65MBs, the resultant XML representation was 175MBs, 2x+ the size. It happens, it’s just how the application deals with the bloat that is the problem. If it grinds everything to a halt, that’s not good

    Jeremy you know I’m quite familiar with FCP XML and FCPX XML. People like Martin Baker, Philip Hodgetts, me and many others helped Apple to make legacy XML import and export better with each release (in most cases).
    So all of ‘us’ learned that not the file size matters, but how fast (and good) the import is handled.

    As I got several requests to integrate FCPX into my TitleExchange I made some tests comparing XMEML (7) to FCPXML (10). File size of v7 XML is for example 26 MB, file size of v10 XML is about 100 k.
    First thought might be v10 XML is more effective – but then you look at the time it takes to import, the 26 MB file is imported into v7 in about 90 seconds (means ready to view and edit) the little v10 XML took more than half an hour. The strange thing is that the v7 XML really carried all information of the original into the copy created by the XML import, while the v10 XML didn’t carry anything else than clips and transitions.
    So Aindreas seems to be right that there is a lot of work needed to make this new kind of data base handling effective – I’m very curious about the next version.
    As for example titles are Motion FX they need to be rendered at least for an export. You can use background rendering or not, using the background version slowed down editing extremely, switching off this rendering made everything ‘normal’, but meant to have a final rendering at the end – in my tests FCPX took 80 to 120 times longer.

    As mentioned by others here any NLE also lives from 3rd party support. Plural Eyes is a good example how to make life easier with FCPX. The demo also shows advantages and disadvantages of the new way of editing.

    Another reaction of Apple I don’t understand (regarding third party): They told the MXF4mac guys that their component is not needed anymore as in FCPX everything is handled natively – would be okay and great. But with P2 everything is copied into a new QT wrapper, though the codec stays native. But this takes more or less the same time as the old L&T and doubles data as well.
    If there would be a good XML support with FCPX I would be able to write a little importer app which really would work with P2 natively using the component and makes import P2 in a few seconds – but people would say: man – look at the price, the whole price is twice as expensive as FCPX. So I don’t create that app that for those two reasons.

    Again my 2 cents

    Andreas

    Spherico
    https://www.spherico.com/filmtools

  • Jeremy Garchow

    December 16, 2011 at 1:53 pm

    Thanks as always for chiming in Andreas. You mention Philip Hodgetts. He seems rather optimistic about FCPXML, at least he thinks it will eventually get more robust.

    [Andreas Kiel] “Another reaction of Apple I don’t understand (regarding third party): They told the MXF4mac guys that their component is not needed anymore as in FCPX everything is handled natively”

    That doesn’t make any sense at all. What I do wonder is if putting an alias file in the event would be better than the l&t method that FCPX currently employs. Native format support is one of my biggest gripes of FCPX, but I’m a nerd.

    Jeremy

  • Andreas Kiel

    December 16, 2011 at 4:41 pm

    Jeremy,

    As I’m a non native English speaker – I don’t know what ‘nerd’ means in this context. 🙂

    The below is OT to the original thread!

    With P2 it’s odd, it’s easy to copy some joined ref files to an event, it takes seconds with the mfx4mac component installed. The problem is that there are no metadata imported into FCPX – might not be a real problem as FCPX ignores or misinterprets some metadata while opening an P2 archive and you have to change or add those anyway. The problem is the XML handling as at the moment there is no metadata handling. And as said it’s a price point.

    Philip is very positive, I from my point do see a lot of work to be done.

    FCPXML is simple, somehow straight forward and robust – as there is ‘nothing’ in there – it’s kind of modern EDL.

    It’s based (also) somehow on the ‘reference’ scheme which was used in legacy XML. While fx and options in FCP got more complicated/extended over the years, references made it more difficult for FCP to resolve them, so from a point of developer view it was much better for the end user NOT to create a small XML which uses references for the matter of import speed, and yes it created much bigger files. But what does file size mean these days?

    In my personal opinion Apple has to rethink the whole XML stuff.
    Look at the effects and effects settings which are not transported via XML.
    As many things are based upon Motion you need to implement Motion XML into FCPXML or find a common XML. Should be doable – but makes it let’s say very special and very complicated.
    Again from my point of view, there is only a little documentation about FCPXML – which is no wonder as there is nothing in there. There is documentation about Motion XML – but this documentation was written in 2010 way before the actual Motion was released, and it doesn’t match the actual Motion file format (I filed a bug and Apple knows about it).
    Again look at my very little niche market with subtitles (only a few thousands of users). Create some subs, create an XML and import the XML you’ve created – all your settings are lost. For me it looks like a lot of work to be done and I’m not that optimistic as Philip is.

    Let’s take another route let’s call it ‘route 1001’ for this (sub)title example. Take a clip and make 2 subtitles used from from the selection offered by FCPX, change each one to match your needs. For subtitles you probably will use one of the ‘Lower Thirds’. With the latest update of FCPX the project will open with the changes you made when you start FCPX again.
    With XML it won’t. So what to do? Take ‘route 1001’ – before you add a build in (sub)Title ctrl-click it and select ‘open a copy in motion’, there you can change font settings etc. Just save it and apply/add to your timeline. Not a big deal. The fx is stored in your ‘User/Movie/Motion Templates/…’. From there on it’s not a build in template anymore but a user template. So with ctrl-click you only got the option open in motion’. You can do the same thing with the title as described above – but never hit cmd-S as it will change all titles in all projects you ever used your ‘custom’ title.
    The result is that your XMLs are still small, but the amount of available titles will bloat and make editing less comfortable, as you have to remember any custom made fx name, at least if you want to work with XML. This not only applies to subtitles but to all Motion based fx.

    As said in my precious post
    my 2 cents

    Andreas

    Spherico
    https://www.spherico.com/filmtools

  • Jeremy Garchow

    December 16, 2011 at 8:13 pm

    [Andreas Kiel] “With P2 it’s odd, it’s easy to copy some joined ref files to an event, it takes seconds with the mfx4mac component installed. The problem is that there are no metadata imported into FCPX – might not be a real problem as FCPX ignores or misinterprets some metadata while opening an P2 archive and you have to change or add those anyway. The problem is the XML handling as at the moment there is no metadata handling. And as said it’s a price point.”

    What is weird though, if you take some footage that has been modified wth P2 Flow, that metadata is in fact imported in to FCPX. it might not show up where you need it to, or where it’s expected, but it is imported which seems to indicate (to me anyway 🙂 that FCPX is reading the P2 XMLs. You do have to go through the archive interface to get there. It is definitely not as straight forward as FCP7 and needs help as you have been pointing out since FCPXML’s inception.

    [Andreas Kiel] “Again look at my very little niche market with subtitles (only a few thousands of users). Create some subs, create an XML and import the XML you’ve created – all your settings are lost. For me it looks like a lot of work to be done and I’m not that optimistic as Philip is.”

    Totally understandable. You know way more about this than I ever will, but doesn’t that mean there’s more “fields” to be added that just aren’t there in FCPXML quite yet? I mean if you look at foolcut, which has been noted to use AXEL, isn’t some of that information carried over? The list of supported parameters is pretty big, so I must assume that the AXEL coordinates haven’t made it in to FCPXML yet?

    From foolcut:

    •reconstructs the primary storyline
    •reconstructs unlimited amount of secondary story lines
    •reconstructs unlimited amount of compound clips
    •reconstructs all anchored clips
    •reconstructs gaps as solids
    •reconstructs custom solid generators with correct color value
    •respect chosen variant in any Audition clip
    •reconstruct cross dissolves
    •recreates original lane order for all timeline elements
    •sets blending modes
    •sets clip name
    •sets opacity values (fixed or animated) including clip’s fade in and fade out
    •sets scale, position, anchor values (fixed or animated) with correct interpretation of FCPX’s spatial conform modes (Fill, Fit or None)
    •sets rotation values (fixed or animated)
    •enable time remap for retimed clips (forward, reverse, slow, fast, ramp etc)
    •sets correct audio dB levels (fixed or animated) including clip’s fade in and fade out
    •supports detached audio / broken apart clip items / split audio
    •sets correct visibility values for disabled clips (audio or video)
    •sets the correct flip or flop value whenever the effect / distortion / flipped is applied to a clip
    •sets the correct frame rate conform values for clips with different rate from the timeline (interprets 24 at 25 etc)
    •sets name and position of time markers
    •creates a dated folder with all the assets in your AE project, sets it to 16bit mode and consolidate footage
    •new option panel lets you choose to relink to original or optimized media
    •creates markers for audio Roles
    •preserve Timecode Startime.
    •support for non-square pixels apect ratios.

    Most effects don’t get carried voer, but that is nothing new when going from FCP Legacy to AE. Some things just don’t carry over, or need to be recreated in the native application.

    [Andreas Kiel] “From there on it’s not a build in template anymore but a user template. So with ctrl-click you only got the option open in motion’. You can do the same thing with the title as described above – but never hit cmd-S as it will change all titles in all projects you ever used your ‘custom’ title.
    The result is that your XMLs are still small, but the amount of available titles will bloat and make editing less comfortable, as you have to remember any custom made fx name, at least if you want to work with XML. This not only applies to subtitles but to all Motion based fx.

    As said in my precious post
    my 2 cents

    Andreas”

    Your input is worth way more than 2 cents! I am asking as I don’t know, but don’t you think FCPX and Motion could potentially get further connected than simply creating a “user effect”, except the language simply isn’t there yet? Maybe not, but yes, there’s a ton of work to do, for sure.

    Jeremy

  • Andreas Kiel

    December 17, 2011 at 2:15 am

    Jeremy.

    It’s always a pleasure to talk to you – even if it’s only in post/thread discussions like now.

    Again OT of the original thread!

    The AXEL format seems to be quite similar to the XML out of FCPX.
    I really admire the foolcut guys as they dived in quickly and more or less reliable gave interchange options (more or less is meant in a very positive way).
    Mysterious AXEL is nothing really supported by Apple officially at this time and it might change any time soon without notification.
    Many of the points you mentioned from foolcut are supported by the current XML export (to be honest I haven’t tried all of them), but I don’t believe that for example ‘•recreates original lane order for all timeline elements‘ is really reliable at this point of time.

    You’re right if you say:

    Most effects don’t get carried voer, but that is nothing new when going from FCP Legacy to AE. Some things just don’t carry over, or need to be recreated in the native application.

    But the problem with XML at this moment is that one: Some things just don’t carry over, or need to be recreated in the native application – and in this case native application means: FCPX.

    But don’t you think FCPX and Motion could potentially get further connected than simply creating a “user effect”, except the language simply isn’t there yet? Maybe not, but yes, there’s a ton of work to do, for sure.

    You’re right, but let me tell a little story.
    Start of story:
    When I was young I had been on a kind of high school which was not held by the city but by the government – so we all were forced to be the best controlled pupils in the country, was bad and fun the same time. Two years before we had to get our ‘mature’ we had have learned everything we needed to do the ‘mature’, so one of our teachers suggested we ‘move’ the mathematics course from the school to the university to learn statistics and Boolean algebra, because that would be the future – all of us did follow and so we learned what a Boolean intersection meant in a logical way. Was 40 years ago.
    End of story!

    So FCPX XML/Format and Motion XML/Format don’t have have a big (if any) intersection at this time – but they didn’t had one before as well.
    One of my favorite examples from text is following: with any app (including any app from Apple except Motion) the font ‘Gill Sans’ is called ‘Gill Sans’, with the actual Motion it’s called ‘GillSans’ – that doesn’t make life easier for both users and developers 😉
    I would love to see a better integration, a common kind of ‘language’. But to be honest, it really will take a lot of time and work to get there – and needs better communication within Apple’s teams.

    It’s late here and I stop at the moment, but more will come. I put another 2 cents on the others a had – that are 6 cents at the moment and with the current exchange rate it’s about 7.8 cents from Europe 🙂

    Andreas

    Spherico
    https://www.spherico.com/filmtools

Page 3 of 4

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