Re: [CinCV] Re: Getting Involved for the GUI?
Hi all This guy (http://pihlaja.wordpress.com/) had started the development of a video editor for linux some months ago and left it. He propose, in this video, a demonstration of the gui of his software. For those who don't have flash player installed, they can download the video on vimeo ==> http://www.vimeo.com/471546 . He also posted some screenshots there ==> http://www.flickr.com/photos/[EMAIL PROTECTED]/1216413443/ Roland (wildhostile) On 2008-03-30 02:32, Ichthyostega wrote: > oops, just forget to say: > I added some of the GUI sketches / proposals of the last time to > the "GUI brainstorming page" on pipawiki: > http://www.pipapo.org/pipawiki/Lumiera/GuiBrainstorming > > Cheers, > Hermann > > > ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Re: Getting Involved for the GUI?
Best to first design the interface between the GUI and the core of the application. Then GUI type decisions can be made by the GUI team without impacting the other sub-projects. Also this helps keep model logic out of the GUI. The interface will need the data structures, the function signatures and also the calling sequences (who calls who, who calls back). -- Regards, Martin ([EMAIL PROTECTED]) IT: http://methodsupport.com Personal: http://thereisnoend.org
Re: [CinCV] capture video with new firewire modules?
Thanks to Nicolas and Holger for help and suggestions. I use an RT kernel most of the time so it's probably easier for me to boot into a non-RT, non-juju 2.6.22 (or less) kernel when I need to capture video. Thanks again, Norv Get the name you always wanted with the new y7mail email address. www.yahoo7.com.au/y7mail ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Re: Getting Involved for the GUI?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 oops, just forget to say: I added some of the GUI sketches / proposals of the last time to the "GUI brainstorming page" on pipawiki: http://www.pipapo.org/pipawiki/Lumiera/GuiBrainstorming Cheers, Hermann -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH7vvLZbZrB6HelLIRAoRgAKDcCj4/GBWadBNcuklb8jTZlpK7yACg5rrC 401eauc0RPYQnhpt0BcdHAk= =nI7x -END PGP SIGNATURE- ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCV] Re: Getting Involved for the GUI?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
>> ...we need people willing to lay the foundations and shape the
>> GUI from scratch.
Joel Holdsworth schrieb:
> That sounds the very exciting to me. The best way to build a frontend
> for this app would be to build a very rich backend interface which
> exposes all required services for the GUI frontend - or any other
> frontend. Strict separation is very important. So of course building a
> good GUI requires a good backend services. Mostly you try and make a the
> GUI a human-friendly wrapper around the backend. Occasionally one has to
> adapt the backend give the right services for a useful frontend.
That's our understanding too.
Incidentally, we want to start out at the level of features and flexibility
we know and value with the current Cinelerra. But we strive at making it more
user friendly at some places where deemed necessary.
Besides, personally I want to push matters a bit, just in the sense of
implementing
the (from a users POV) already rather modular approach of Cinelerra more
consequently.
Btw, I am implementing the Proc Layer (middle Layer) of the application, where
the
"Media Objects" in the session are hold and the edit operations are carried out,
while Chrisian Thaeter ("cehteh") is the "Master of the Backend".
See here for an architecture draft/overview: (I know, the drawing needs some
work)
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ArchitectureOverview
So, while we want to integrate Plugins on various levels and while we want
"everything is an object and can be wired freely" (from a users point of view),
we as well want to support a smooth workflow, especially in large projects, and
thus need to provide some automatism to manage all of this configurability
As you just said, make a human-friendly wrapper...
> At the moment it doesn't look like much has been done on the UI side of
> things. But I'd love to get the ball rolling on the design. Do you or
> anyone else have ownership of this? - or am I the sole volunteer? I see
> some basic design ideas, but has anyone actually begun to work toward a
> concrete spec which could actually be implemented?
Your are right: contrary to backend and proc layer, where we have concrete specs
and are in the middle of coding, we don't have any finished plans or concepts
for the GUI. So, if you are willing to get the ball rolling, you are welcome.
To summarize:
- Richard Spindler kept the GUI discussion rolling (thanks, Richard!).
He wrote Open Movie Editor and thus doesn't want to become the Lumiera
GUI Master, if I understand him right. But he will contribute here and
there and we plan to share code and common experiences on various levels.
- "Paulo Alves Pereira" <[EMAIL PROTECTED]> asked to get involved.
He worked as editor and camera man and proposed last week to write a draft
based on his experiences with AVID (which he rather likes and proposes
to use as a model for a smooth professional workflow). I don't know if
Paulo is on thins ML -- I'll keep him informed.
- several other people showed interest and will probably join a GUI working
group (but mostly have not the time or can't code enough to take the
respsibility for a whole subsystem)
Especially I remember Sami Kallinen, SimAV, maybe Plouj?
My impression is, if we manage to create a GUI concept and lay the foundations
for the implementation, many more people are willing to help and code down
individual functions or do graphics/design work, if there is a viable starting
point for them to "jump in"
cheers,
Hermann
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFH7vl2ZbZrB6HelLIRAu6vAJ9K/sW/bhcfKPhxxnfUySOudoY4oACePe+X
fcTfgWJMdE36KkigUF+Tdyo=
=Q3rm
-END PGP SIGNATURE-
___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Getting Involved for the GUI?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andreas Hermann Braml schrieb: > Doesn't that mean that the choice of the GUI framework (=toolkit?) to > use is not that important, since the core is not tied to the GUI, but > just interacts with it via clearly defined interfaces? yes, exactly, that's the intention > those who write the /first/ GUI decide > what interfaces they need and how those should be structured, but that > does not prevent other GUIs to be written on top of the core layers, > using another toolkit, as long as they use the interfaces. It should be added that writing a complete GUI for a professional App is no small task, so we are glad if anyone starts this GUI thing. Naturally, the one volunteering first gets many opportunities to shape the whole application which is emerging, and his work has good chances to become "the" GUI. But this doesn't mean that we couldn't have several GUIs, e.g. one simple and one with many bangs and whistles. As long as we keep clean interfaces and sort of a common understanding of terms and procedures, and don't end up in a war of competing GUIs, we'll be fine... Cheers, Hermann > I started to work those through, and although I don't understand C/C++ > sufficiently - yet - the concepts accumulated in the first design drafts > are fascinating, even for me that I usually just do the video editing, > not the coding. PS :We especially invite people involved in (professional or ambitious amateur) video/film editing to participate in the GUI design, even if they can't code themselves, because those are our primary intended audience -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH7vFDZbZrB6HelLIRAnbtAJwL0rs4f4fjATwVUIf8pzIF1D3HAACgpupI mDnnAG1KseVXNL7SFun0c2w= =rT+a -END PGP SIGNATURE- ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCV] Cinelerra CV 2.1 on FreeBSD
Hello, first: don't expect this post to proclaim that I successfully ported Cinelerra CV to run natively on FreeBSD. I did not, unfortunately. What I succeeded in is taking the version for Fedora Core 4 and get it to run on the FreeBSD Linuxolator of 7.0-RELEASE. It wasn't that hard, most of the work was finding RPMs for the libraries Cinelerra depends on (OpenEXR etc.). Some of the dependencies could be installed via the FreeBSD ports system, for everything not there which is part of Core, I hacked some ports of my own. The packages in the Extras repository were a bit more work; I had to track them down on rpmsearch and install manually, but not too hard. In fact, it was always the same steps, so I wrote a script the automates the download and install. It might eat your cat (or at least the movie you made of your cat and which you are now editing in Cinelerra), but it works for me. I have to stick with this solution for the time being, because Cinelerra (or is that XCB?) bug 406 bites me hard. I put the custom ports and the install script up on my webspace in a tar.bz2. You can find more information in the INSTALL file contained therein. All the usual disclaimers apply. And note that the package of CinelerraCV is quite dated, from October 2006. All that said, you can find the tarball here: http://braml.org/CinelerraCVOnFreeBSD-20080330.tar.bz2 Andreas, aka pseudoruprecht signature.asc Description: OpenPGP digital signature
Re: [CinCV] Getting Involved for the GUI?
Hi ichthyo, Ichthyostega wrote: > [...] > We have put > up the requirement, that everything within the session (edit operations, > rendering) > must work in "headless" operating mode, i.e. script driven, without a GUI. So > everyone > working on the GUI will have to cooperate with the people working at the > backend layer > or the proc layer and agree on suitable interfaces for doing things and > exchange data. > So, basically, for Lumiera you can't just /contribute/ to the GUI, rather, we > need > people willing to lay the foundations and shape the GUI from scratch. (And > this > includes the decision what GUI framework to use) Doesn't that mean that the choice of the GUI framework (=toolkit?) to use is not that important, since the core is not tied to the GUI, but just interacts with it via clearly defined interfaces? Or am I totally wrong here? Perhaps you mean: those who write the /first/ GUI decide what interfaces they need and how those should be structured, but that does not prevent other GUIs to be written on top of the core layers, using another toolkit, as long as they use the interfaces. Or am I oversimplifying matters here? > For Lumiera, we *do* have lots of drafts, plannings, documentation (and even > some > code ;-) ). So, most important, if interested: speak up, ask questions, ask > for pointers! > See: http://www.pipapo.org/pipawiki/Lumiera/QuickStart I started to work those through, and although I don't understand C/C++ sufficiently - yet - the concepts accumulated in the first design drafts are fascinating, even for me that I usually just do the video editing, not the coding. Andreas signature.asc Description: OpenPGP digital signature
[CinCV] Re: Getting Involved for the GUI?
John Coswell: I must say you've made a very promising start with the Tango stuff. I love Tango, and it's great to see people adopting everywhere. Certainly a lot better than the MS Paint icon set that Cinelerra has at the moment. Ichthyostega: > So, basically, for Lumiera you can't just /contribute/ to the GUI, > rather, we need people willing to lay the foundations and shape the > GUI from scratch. (And this includes the decision what GUI framework > to use) That sounds the very exciting to me. The best way to build a frontend for this app would be to build a very rich backend interface which exposes all required services for the GUI frontend - or any other frontend. Strict separation is very important. So of course building a good GUI requires a good backend services. Mostly you try and make a the GUI a human-friendly wrapper around the backend. Occasionally one has to adapt the backend give the right services for a useful frontend. > For Lumiera, we *do* have lots of drafts, plannings, documentation > (and even some code ;-) ). So, most important, if interested: speak > up, ask questions, ask for pointers! See: > http://www.pipapo.org/pipawiki/Lumiera/QuickStart At the moment it doesn't look like much has been done on the UI side of things. But I'd love to get the ball rolling on the design. Do you or anyone else have ownership of this? - or am I the sole volunteer? I see some basic design ideas, but has anyone actually begun to work toward a concrete spec which could actually be implemented? I want to get to work as soon as possible! Thanks Joel On Sat, 2008-03-29 at 21:36 +0100, Ichthyostega wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Joel Holdsworth schrieb: > > I'm thinking of getting involved with development on > > cinelerra/luminerra, so I thought I'd say hello on this mailing list. > > For the last year or so, I've been working with the inkscape guys, > > honing some UI issues. At the moment though, given that they now have > > 100 developers on team, it looks to me like they have enough people, > > and things seem to be going along nicely. > > > > My bread and butter is really GUI work, and so I'd be really interested > > in getting involved with the Gtkmm or Qt migration - if that's still > > happening. In GUIs I always try and work toward intuitive, tidy, > > rule-abiding, quality; and so it seems to me that maybe I'd have > > something to contribute Cinelerra. > > > > For myself, I've mostly worked in Win32 and Gnome. I've used gtkmm a > > fair bit, and I would say that it is excellent. So is it possible to get > > involved with the UI work? and if so how can I do that? > > John Coswell schrieb: > > I guess this is as good a time as any to introduce myself as well. Like > > Joel, I work on Inkscape, have some C++ experience, have used Cinelerra for > > a handful of productions, and have a keen interest in getting Lumiera (and > > Cin-CV while we need it) working really well for my future productions. To > > get acclimated to the current codebase, I've been experimenting with > > creating a new theme for Cinelerra based on the Tango desktop > > specification, with the correct colors and appropriate icons, so that it > > better integrates visually with a majority of the modern Linux graphic > > design applications. So far, I've only gotten a handful of dialogs > > converted over, but I hope to work on finishing the rest soon, if there's > > interest in having that look with the current application. > > > > So long story short, I'm interested in helping out in small batches with > > Cinelerra and Lumiera when I have a chance, if youall will have me. :) > > > Hi Joel, > Hi John, > > first of all -- thanks for volunteering to help. You are welcome! > > There were already lots of responses in this thread. I'll just give some > additional > explanations. We have two applications: the existing Cinelerra-2.1 codebase > and > the now completely separate new Lumiera codebase. The situation is quite > different > for these. > > Cinelerra uses a "homemade" GUI toolkit called "Guicast". This one works > quite well, > but is seemingly used only in this application and is not as polished as any > of the > widely used GUI toolkits out there. More of a problem here is, that there > obviously > is not much structure or layering in there. You'll find much of the > applications > behaviour scattered within the various key and mouse event callbacks. So, in > my > opinion, the best thing you can do is to pick some feature that is deemed > worth > to be improved, and just go ahead and try to rework it in place. None of us > can make any predictions if the "upstream" author of Cinelerra will take your > patch or just ignore it or, even worse, decide to do something quite different > in this area, which will leave dealing with the resulting collisions to the > community. > > Lumiera OTOH is build ground up, starting form the engine core. Nothing > besides > brainstorm
[CinCV] Getting Involved for the GUI?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joel Holdsworth schrieb: > I'm thinking of getting involved with development on > cinelerra/luminerra, so I thought I'd say hello on this mailing list. > For the last year or so, I've been working with the inkscape guys, > honing some UI issues. At the moment though, given that they now have > 100 developers on team, it looks to me like they have enough people, > and things seem to be going along nicely. > > My bread and butter is really GUI work, and so I'd be really interested > in getting involved with the Gtkmm or Qt migration - if that's still > happening. In GUIs I always try and work toward intuitive, tidy, > rule-abiding, quality; and so it seems to me that maybe I'd have > something to contribute Cinelerra. > > For myself, I've mostly worked in Win32 and Gnome. I've used gtkmm a > fair bit, and I would say that it is excellent. So is it possible to get > involved with the UI work? and if so how can I do that? John Coswell schrieb: > I guess this is as good a time as any to introduce myself as well. Like > Joel, I work on Inkscape, have some C++ experience, have used Cinelerra for > a handful of productions, and have a keen interest in getting Lumiera (and > Cin-CV while we need it) working really well for my future productions. To > get acclimated to the current codebase, I've been experimenting with > creating a new theme for Cinelerra based on the Tango desktop > specification, with the correct colors and appropriate icons, so that it > better integrates visually with a majority of the modern Linux graphic > design applications. So far, I've only gotten a handful of dialogs > converted over, but I hope to work on finishing the rest soon, if there's > interest in having that look with the current application. > > So long story short, I'm interested in helping out in small batches with > Cinelerra and Lumiera when I have a chance, if youall will have me. :) Hi Joel, Hi John, first of all -- thanks for volunteering to help. You are welcome! There were already lots of responses in this thread. I'll just give some additional explanations. We have two applications: the existing Cinelerra-2.1 codebase and the now completely separate new Lumiera codebase. The situation is quite different for these. Cinelerra uses a "homemade" GUI toolkit called "Guicast". This one works quite well, but is seemingly used only in this application and is not as polished as any of the widely used GUI toolkits out there. More of a problem here is, that there obviously is not much structure or layering in there. You'll find much of the applications behaviour scattered within the various key and mouse event callbacks. So, in my opinion, the best thing you can do is to pick some feature that is deemed worth to be improved, and just go ahead and try to rework it in place. None of us can make any predictions if the "upstream" author of Cinelerra will take your patch or just ignore it or, even worse, decide to do something quite different in this area, which will leave dealing with the resulting collisions to the community. Lumiera OTOH is build ground up, starting form the engine core. Nothing besides brainstorming has been done for the Lumiera GUI yet. Learning from the problems with the Cinelerra code base, we care much for modularity and clear interfaces: We have put up the requirement, that everything within the session (edit operations, rendering) must work in "headless" operating mode, i.e. script driven, without a GUI. So everyone working on the GUI will have to cooperate with the people working at the backend layer or the proc layer and agree on suitable interfaces for doing things and exchange data. So, basically, for Lumiera you can't just /contribute/ to the GUI, rather, we need people willing to lay the foundations and shape the GUI from scratch. (And this includes the decision what GUI framework to use) For Lumiera, we *do* have lots of drafts, plannings, documentation (and even some code ;-) ). So, most important, if interested: speak up, ask questions, ask for pointers! See: http://www.pipapo.org/pipawiki/Lumiera/QuickStart Hermann Vosseler (aka "ichthyo") -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH7qhLZbZrB6HelLIRAgH1AJ9JOtpVq7H1HslVGu2tPMExH5YtlgCg4UC7 YjXv9719VuzOD/1DT5B5iCA= =wm0e -END PGP SIGNATURE- ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Can I Get Involved?
On Sat, 29 Mar 2008 01:32:24 +0100, Burkhard Plaum <[EMAIL PROTECTED]> wrote: Hi, On Fri, 28 Mar 2008 22:25:38 +0100, Richard Spindler <[EMAIL PROTECTED]> wrote: Fancy titles can be made as overlay images in a separate app. But titles that will play nice in interlaced standard definition with a partially analogue signal path requires special care. What else except rendering characters per field and maybe a bit blurring (do decrease high frequency components) has to be considered here? Clamping the luma to a little less than 100%. Though this is to prevent overshooting, which is reduced by blurring. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCV] [Announce] Third Open Video Developer meeting, aka First Lumiera Developers meeting
Hi folks, our next Developer meeting is scheduled on Tuesday the 3. April 2008 at 21:00 GMT We know that this time is uncomfortable for people downunder and far east, please speak up urgendly with other time proposals if you want to attend! This time we will held the meeting on irc.freenode.net in #lumiera which is our new project channel. The agenda for this meeting is at (down the page) http://www.pipapo.org/pipawiki/Lumiera/MonthlyMeetings There isnt really much yet, maybe we could make it this time 'in time' but anyways, please contribute Topics when you have ideas. Sidenote: our server at http://lumiera.org is up, no shiny page yet. I just copied the docs and other useful information up. The git repositories are working too (sans anonymous uploadable mob repos, I will set them up on demand). Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] capture video with new firewire modules?
Hi, On Friday 28 March 2008 11:53, KH KH wrote: > You need to backlist the new juju firewire modules and that's all. > No need to rebuild the whole kernel for theses. > (only eth1394 cannot be rebuild that way). I'm providing sid kernels for Debian, which the only change compared to sid, that they additionally have the old firewire stack enabled. More information is available at http://layer-acht.org/blog/debian/#1-155 regards, Holger, who is excited to read about progress with juju here... pgpUOw5am32JP.pgp Description: PGP signature
Re: [CinCV] P2 or Red Proxies
2008/3/29, Burkhard Plaum <[EMAIL PROTECTED]>: > Can be unzipped with unzip. It creates a directory, which contains an xml > file and one mxf file for each A/V stream. If I interpret the xml correctly, > and the MXFs are clip-wrapped, this can be decoded even without an MXF > demuxer because the xml file already contains the start offset of the > Data, the video codec and and the size. That's enough to fire up a raw-dv > parser. Indeed, this is also the case for the P2 samples that I have, I guess this will make an implementation quite easy, I think I can do a tiny utility to copy the contents into a raw DV file, this should make it easier for existing software to handle the footage, I guess. Cheers -Richard -- Don't contribute to the Y10K problem! ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
