Comments on: The struggle of Pitivi http://blogs.gnome.org/uraeus/2006/11/22/the-struggle-of-pitivi/ GStreamer and Collabora news and more Sat, 11 Feb 2012 05:07:28 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Aidan Delaney http://blogs.gnome.org/uraeus/2006/11/22/the-struggle-of-pitivi/comment-page-1/#comment-654 Aidan Delaney Wed, 30 Nov -0001 00:00:00 +0000 http://blogs.gnome.org/uraeus/2006/11/22/the-struggle-of-pitivi/#comment-654 Christian,<br/>I was wondering if it would be useful to make the PiTiVi sound channel accept Jokosher projects. As such Jokosher could take care of the audio editing and transcoding. PiTiVi would then /only/ have to deal with editing video and cutting the Jokosher sound track.<p/>As such PiTiVi/Jokosher would form a suite of tools which could be used together. Clicking on a PiTiVi sound channel to edit it, would open Jokosher. Thus PiTiVi could concentrate on non-linear video editing i.e. doing one thing well. Christian,
I was wondering if it would be useful to make the PiTiVi sound channel accept Jokosher projects. As such Jokosher could take care of the audio editing and transcoding. PiTiVi would then /only/ have to deal with editing video and cutting the Jokosher sound track.

As such PiTiVi/Jokosher would form a suite of tools which could be used together. Clicking on a PiTiVi sound channel to edit it, would open Jokosher. Thus PiTiVi could concentrate on non-linear video editing i.e. doing one thing well.

]]> By: Laszlo http://blogs.gnome.org/uraeus/2006/11/22/the-struggle-of-pitivi/comment-page-1/#comment-655 Laszlo Wed, 30 Nov -0001 00:00:00 +0000 http://blogs.gnome.org/uraeus/2006/11/22/the-struggle-of-pitivi/#comment-655 Aidan, (i'm a jokosher dev and) this has been discussed in the past, but the main problem would be integrating the two projects without making it feel like a kludge. This is what adobe does when you have the whole suite of their products installed, but changing entire interfaces is not smooth, and I don't think would be very usable. But if you want to propose something that you think would work, we're all ears. Aidan, (i’m a jokosher dev and) this has been discussed in the past, but the main problem would be integrating the two projects without making it feel like a kludge. This is what adobe does when you have the whole suite of their products installed, but changing entire interfaces is not smooth, and I don’t think would be very usable. But if you want to propose something that you think would work, we’re all ears.

]]> By: Joseph http://blogs.gnome.org/uraeus/2006/11/22/the-struggle-of-pitivi/comment-page-1/#comment-656 Joseph Wed, 30 Nov -0001 00:00:00 +0000 http://blogs.gnome.org/uraeus/2006/11/22/the-struggle-of-pitivi/#comment-656 I would agree that a jokosher link would be nice, but I want basic audio editing available directly within pitivi. For instance, I had a screencast that had the music missing, so I wanted to slice out the audio after the initial commentary ended, and then insert auido. I don't want to open another app to do this; it's a very basic operation.<p/>Maybe you could add an "Advanced" editing option, which edits with jokosher? I agree that there's overlap, but it needs to be done smoothly.<p/>Similarly, being able to paint on the windows to do basic emphasis would be nice (e.g. circling action). I would agree that a jokosher link would be nice, but I want basic audio editing available directly within pitivi. For instance, I had a screencast that had the music missing, so I wanted to slice out the audio after the initial commentary ended, and then insert auido. I don’t want to open another app to do this; it’s a very basic operation.

Maybe you could add an “Advanced” editing option, which edits with jokosher? I agree that there’s overlap, but it needs to be done smoothly.

Similarly, being able to paint on the windows to do basic emphasis would be nice (e.g. circling action).

]]> By: Joseph http://blogs.gnome.org/uraeus/2006/11/22/the-struggle-of-pitivi/comment-page-1/#comment-657 Joseph Wed, 30 Nov -0001 00:00:00 +0000 http://blogs.gnome.org/uraeus/2006/11/22/the-struggle-of-pitivi/#comment-657 Any timeframe for the slicing and splicing? I needs it pretty badly for some videos I've done. I'd thought it was further along. :(<p/>[also, if you could provide .debs for ubuntu.... :] Any timeframe for the slicing and splicing? I needs it pretty badly for some videos I’ve done. I’d thought it was further along. :(

[also, if you could provide .debs for ubuntu.... :]

]]> By: Luis http://blogs.gnome.org/uraeus/2006/11/22/the-struggle-of-pitivi/comment-page-1/#comment-658 Luis Wed, 30 Nov -0001 00:00:00 +0000 http://blogs.gnome.org/uraeus/2006/11/22/the-struggle-of-pitivi/#comment-658 I'm not a developer myself, but I would think that Pitivi is a very attractive project to join for a developer. First, because it must be fun to work on a video editor, and also because it's written in Python (the most developer friendly language AFAIK). I guess that once you release something that's useful for basic editing it will attract more attention from users and developers. I really wish you good luck. A video editor is really needed in Linux. And now that the Diva project seems abandoned (?) Pitivi is even more important. I’m not a developer myself, but I would think that Pitivi is a very attractive project to join for a developer. First, because it must be fun to work on a video editor, and also because it’s written in Python (the most developer friendly language AFAIK). I guess that once you release something that’s useful for basic editing it will attract more attention from users and developers. I really wish you good luck. A video editor is really needed in Linux. And now that the Diva project seems abandoned (?) Pitivi is even more important.

]]> By: Mark http://blogs.gnome.org/uraeus/2006/11/22/the-struggle-of-pitivi/comment-page-1/#comment-659 Mark Wed, 30 Nov -0001 00:00:00 +0000 http://blogs.gnome.org/uraeus/2006/11/22/the-struggle-of-pitivi/#comment-659 Is there a possibility of a rethink on the gstreamer Python port? A Ctypes approach would a) exactly match the gstreamer API, would therefore b) have complete documentation, and c) be easier to maintain and stay current w/ gstreamer. Is there a possibility of a rethink on the gstreamer Python port? A Ctypes approach would a) exactly match the gstreamer API, would therefore b) have complete documentation, and c) be easier to maintain and stay current w/ gstreamer.

]]>