Re: [CinCV] test, cinelerra on 64bit Hardy Heron
Andreas Hermann Braml ha scritto: I had similar problems (on x86). I had to do both of the following to get Cinelerra (akirad packages) to work here: - get the latest kernel from -proposed (not 100% sure if this is really necessary) - start cinelerra with LIBXCB_ALLOW_SLOPPY_LOCK=true Cinelerra (I got the hint here: https://bugs.launchpad.net/ubuntu/+source/synergy/+bug/182825) This is not beautiful, but definitely better than sudo. pseudoruprechtl Thanks a LoT!!! I provide to update my repository as soon I can! Also I add your name to the thanks pages! ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Lumiera design
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thorsten Wilms schrieb: > I wouldn't rule out making Ardour also work on a per object level. ...which would mean throwing out and rewriting a good deal of the editing core (not the audio processing part and not gui specific things). Remember, the original poster asked why not build Lumiera on top of Ardour? Now, this is the answer! > On Sat, 2008-05-17 at 18:44 +0200, Ichthyostega wrote: >> There seems to be a compelling idea buried within this approach, >> but we'd need to nail down how each of this "things" can be >> attached to this common automation. And, moreover, what to do if >> your "things" are moved and rearranged? Leave the automation where >> it is? Extract a part of the automation and move it alongside with >> the "thing". And is this really helpful for the user? Thorsten Wilms schrieb: > In the end you would have a nodal system with free routing of audio, > video and automation (perhaps several types of the later). Tracks and > busses would just be wrappers/proxies. > > Lets say automation tracks have outputs and everything that can be > automated has inputs (could be more than 1 type, though). ... > There can be 1:n connections just like with audio routing. There > should be plugins for at least simple math operations. > > Regions would have their own i/o, automatically connected to the i/o > of their track. Here you are giving a concise summary of what our current design and started implementation of Lumiera is about; so probably, we'll agree in the end result. :) > Regarding moving stuff around, there could be a locking feature (lock > point A on track 1 to point B on track 2). Lots of fun because you > might want to express the relative distance in wall clock time, > frames or bars:beats ... To deal with this problem, I devised a concept I call "Placement". Every Object in the Session is handled and attached by means of a Placement, which has the purpose to stick the object "at" some location. But "location" can be more general: some point in time, some point in our tree of tracks, a specific output destination port, some layer for layered video mixing or some pan position for sound. Properties of placement, which are not specified locally, are derived from the context, which gives us e.g. the automatic connections you proposed above, as well as a global or per track layer and pan (if we want it). Placement can be - absolute (fixed values) - relative to another object (clip, plugin, label) - relative to a specific source position in another clip (e.g. a flap) - attached to another object (for effects, transitions) without much problems, Placement could be extended to employ rules or e.g. to place an object repeatedly according to some pattern function. Meaning there is a lot of potential for interesting future extensions without changing the inner mechanics. Cheers, Hermann -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIL28qZbZrB6HelLIRAtn+AJ9jax6MGsVvx6Dyg3S0H6tFgnE37wCfYY7h jaHjYTrHQLDiqlXVeLoEtLY= =Odhe -END PGP SIGNATURE- ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Re: [CinCVS] Inverted colours and garbled audio in DV video on PowerPC build (Debian Sid). Endianness issues?
On Sat, 17 May 2008 22:41:52 +0200, Herman Robak <[EMAIL PROTECTED]> wrote: > If I choose the X11-XV driver, colours are inverted all the > time. If I use X11 or OpenGL, the colours are normal during > playback, but pink/green when it stops. Playback is also > slooow, around 3 fps. If I add an effect, or use the video fader, I get much milder colour distortion with the OpenGL driver. But the OpenGL pipe- line has other bugs; HDV media gets distorted colours during playback with OpenGL, but is fine with XV and X11. And before anyone says "works for me"; this is on a G4 PowerPC, running Debian Lenny. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCV] Re: [CinCVS] Inverted colours and garbled audio in DV video on PowerPC build (Debian Sid). Endianness issues?
On Thu, 26 Oct 2006 00:22:54 +0200, Herman Robak <[EMAIL PROTECTED]> wrote: > [...] PAL DV media are shown with inverted colours and garbled sound, both > in the Viewer and the compositor. The thumbnails on the timeline and > the Media folder have correct colours. > > MPEG1 media come out right. > > Sounds familiar? I'm building Cinelerra on Debian PowerPC again, on a Mac mini. This time on Lenny (testing). Kino no longer displays DV with weird colours, and Kino's playback is smooth. But Cinelerra still has problems. If I choose the X11-XV driver, colours are inverted all the time. If I use X11 or OpenGL, the colours are normal during playback, but pink/green when it stops. Playback is also slooow, around 3 fps. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Build problem on Debian for PowerPC, due to pkg-config.
On Sat, 03 May 2008 14:33:04 +0200, Herman Robak <[EMAIL PROTECTED]> wrote: > When I try to build the latest Cinelerra (revision 1056) on a PowerPC > Mac mini running Debian Lenny (testing), the configure script aborts > with the error > > ./configure: line 23421: syntax error near unexpected token `MJPEG,' > `PKG_CHECK_MODULES(MJPEG,mjpegtools,mjpegtools=yes,:)' > > This is the first line of pkg-config directives in the ./configure file. Running autogen.sh again resolved the problem. autogen.sh has to be run _after_ pkg-config is installed. If it is only run _before_ pkg-config is installed, pkg.m4 is not included in aclocal.m4, and ./configure will fail at the first pkg-config macro. autogen.sh is supposed to be run only once after checking out the source code. This generates configure and a few other files. The user may not know all the dependencies before configure has been run, so I think autogen.sh needs to check for pkg-config. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Lumiera design
On Sat, 2008-05-17 at 18:44 +0200, Ichthyostega wrote: > Hi Thorsten, > > your response is somewhat confusing for me -- basically I don't know > if you are a user or a developer. Think of me as something in between ;) > If you are mainly a user, you should > consider that for implementing things, we need to be 100% precise, up > to the last tiny and boring detail you never even wanted to know it > existed. "..should allow controlling several things with one automation > track" is by far to fuzzy! There seems to be a compelling idea buried > within this approach, but we'd need to nail down how each of this > "things" can be attached to this common automation. And, moreover, > what to do if your "things" are moved and rearranged? Leave the > automation where it is? Extract a part of the automation and move > it alongside with the "thing". And is this really helpful for the > user? In the end you would have a nodal system with free routing of audio, video and automation (perhaps several types of the later). Tracks and busses would just be wrappers/proxies. Lets say automation tracks have outputs and everything that can be automated has inputs (could be more than 1 type, though). For convenience, audio tracks have a menu to add automation tracks that are already wired to gain, pan, etc. There can be 1:n connections just like with audio routing. There should be plugins for at least simple math operations. Regions would have their own i/o, automatically connected to the i/o of their track. Regarding moving stuff around, there could be a locking feature (lock point A on track 1 to point B on track 2). Lots of fun because you might want to express the relative distance in wall clock time, frames or bars:beats ... > We were talking about design. This mandates us to restrain ourselves > from "I can do this and that" and step back. Rather, the question is, > to find a general approach such that the greatest number of issues > and problems just "falls into place", rather then necessitating > the invention of clever solutions for this and that. Oh, I'm all for solving problems with the lowest number and complexity of concepts necessary to get the job done efficiently :) I wouldn't rule out making Ardour also work on a per object level. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Lumiera design
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thorsten Wilms schrieb: >>> Well, it would make perfect sense to add per region effects to >>> Ardour ;) > You could just have automation tracks that are not tied to other > tracks. That should allow controlling several things with one > automation track and processing stages between automation and > destinations. Hi Thorsten, your response is somewhat confusing for me -- basically I don't know if you are a user or a developer. If you are mainly a user, you should consider that for implementing things, we need to be 100% precise, up to the last tiny and boring detail you never even wanted to know it existed. "..should allow controlling several things with one automation track" is by far to fuzzy! There seems to be a compelling idea buried within this approach, but we'd need to nail down how each of this "things" can be attached to this common automation. And, moreover, what to do if your "things" are moved and rearranged? Leave the automation where it is? Extract a part of the automation and move it alongside with the "thing". And is this really helpful for the user? In Ardour, indeed, automation stays fixed to the track and this is a mayor obstacle in the production workflow. Personally, I'm using a bunch of python scripts to be at least able to move automation data (I've spent weeks to create) in case the customer wants some correction afterwards. Cinelerra at least allows to copy/past keyframes, which is vastly superior, but far from perfect. It dodges the problem of how to combine pasted automation data with the data already there. Ideally, I'd want the automation data to follow the objects automatically. Now, you could easily jump into inventing clever mechanisms for this and that, but -- hold on! We were talking about design. This mandates us to restrain ourselves from "I can do this and that" and step back. Rather, the question is, to find a general approach such that the greatest number of issues and problems just "falls into place", rather then necessitating the invention of clever solutions for this and that. To summarize my argument: Ardour's main strength is the real-time capable wiring of a virtual sound studio environment. This is achieved by building on JACK. Thus, Ardour is necessary track/bus-centric. The editing and arranging of source material is subordinated to this principle and solved by employing a track-wide entity called "playlist". For Lumiera, we take a much more object-centric aproach, which decreases the importance of the tracks, but brings us to have to deal with the wiring in a more active manner, and also to organize the actual calculations differently (we employ pull-processing). > > I agree that video leads to requirements that reach into the audio > realm. Without a doubt making an app that is good at both video and > audio is extra hard. It's just that you would need an insane amount > of work to get even close to Ardour's audio editing and routing > capabilities. Starting any larger software development project is an act near to insanity. Somewhat similar to wanting to climb a mountain. You need to ignore the hugeness of the task and keep going. > Given a special interest in music videos, I see a hard separation of > editing audio and editing video as a problem. I agree fully with you regarding the importance of this point. To my understanding, you should be able to get to the level of a complete draft of the soundtrack within the editing/compositing App. On the other hand, a dedicated DAW has its own strengths we shouldn't try to compete with. Think for example at overdubbing. So, probably we'll have to care for a viable session exchange mechanism, so you could take your draft tracks over to the DAW for the sound specific work and bring some finished chunks back into the video session. Cheers, Hermann -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFILwt8ZbZrB6HelLIRAmhrAKDpUeNT/Cdj/gZu6QAt3n/qzlLvngCfVPkw 4Jof42h6nBjr4LxHiTSYClk= =pOqX -END PGP SIGNATURE- ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] test, cinelerra on 64bit Hardy Heron
Am Donnerstag 08 Mai 2008 23:22:59 schrieb august: > > august ha scritto: > > >4.) the Akirad packages are still causing problems for me. > > > I hear the workaround is to do sudo cinelerra...but I > > > don't want to do that with my current permissions setup. > > > any ideas for a fix > > > > Now the packages works great also on hardy, have you try to > > do > > > > sudo chown youruser:yourgroup ~/.bcast ? > > yes, I have. I just did a reinstall from akirad yesterday. > I also set the audio to work with esound. > > I've also tried running cinelerra by 'sudo cinelerra' > > What I get is really wierd random errors. Sometimes when I > start cinelerra, it just freezes. Every 5th or 6th time, > however, it doesn't. I don't get this. > > Also, if I do get it open and it behaves well...then when I go > to render it freezes...but, again, only sometimes. > I had similar problems (on x86). I had to do both of the following to get Cinelerra (akirad packages) to work here: - get the latest kernel from -proposed (not 100% sure if this is really necessary) - start cinelerra with LIBXCB_ALLOW_SLOPPY_LOCK=true Cinelerra (I got the hint here: https://bugs.launchpad.net/ubuntu/+source/synergy/+bug/182825) This is not beautiful, but definitely better than sudo. pseudoruprecht -- My 5 today: #203724 (wine), #230883 (kdebase-kde4) Do 5 a day - every day! https://wiki.ubuntu.com/5-A-Day signature.asc Description: This is a digitally signed message part.
Re: [CinCV] Lumiera design
On Sat, 2008-05-17 at 01:03 +0200, Ichthyostega wrote: > Thorsten Wilms schrieb: > > Well, it would make perfect sense to add per region effects to Ardour ;) > > of course it would be nice... I'd love it ;-) > as well as crossfades between more then two adjacent clips, > and effects spanning several clips, ... > -- and then where would you put the automation? and how should this > fit in with the concept of "playlists" and "diskstreams" Ardour > builds upon? You could just have automation tracks that are not tied to other tracks. That should allow controlling several things with one automation track and processing stages between automation and destinations. In short: free routing and plugins for automation. With both an extended Ardour or something from scratch, it should be considered to have objects on the timeline that represent the lifespan of plugins and connections. I agree that video leads to requirements that reach into the audio realm. Without a doubt making an app that is good at both video and audio is extra hard. It's just that you would need an insane amount of work to get even close to Ardour's audio editing and routing capabilities. Given a special interest in music videos, I see a hard separation of editing audio and editing video as a problem. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
