_______________________________________________ Lumiera mailing list Lumiera@... http://lists.lumiera.org/cgi-bin/mailman/listinfo/lumiera
Bert Debuck wrote: > Would it be possible to make the program to run on OS X as well? > I'd love that!! > Thanks, > Bert OS X is POSIX conforming (more or less), we do not specially target it but maintaining a port to it should be doable. That means there will be no specific use of the Apple Api's (Quarz/Cocoa, .. and whatever else is there), it might need an xserver and so on. Nicholas showed interest there, if there is someone else who want to help, just jump on board and help. Christian
Hi, Christian Thaeter wrote > Bert Debuck wrote: > OS X is POSIX conforming (more or less), we do not specially target it > but maintaining a port to it should be doable. Some time ago I ported the whole gmerlin to OSX. It was a bit crashy (but worked) and the owner of the MAC is short of time. 2 important things I stumbled upon: - Posix semaphores are not implemented. The functions are there but always return an error - Configuring a socket such that writing when the other end disconnected returns an error instead of a SIGPIPE is done differently on Linux and OSX. Not sure if there is an official Posix was to do this. The corresponding configure checks and a BSD-licensed semaphore implementation are in the gmerlin(-avdecoder) trees. Burkhard
Burkhard Plaum wrote: > Hi, > > Christian Thaeter wrote >> Bert Debuck wrote: >> OS X is POSIX conforming (more or less), we do not specially target it >> but maintaining a port to it should be doable. > > Some time ago I ported the whole gmerlin to OSX. It was a bit crashy (but > worked) and the owner of the MAC is short of time. 2 important things I > stumbled upon: > > - Posix semaphores are not implemented. The functions are there but > always return an error I try to avoid semaphores anyways, prefering mutexes (they are faster on linux, have more sane semantic). Note that there is a option to posix mutexes that make them shared over processes, iirc thats not implemented in linux/glibc, but maybe it helps you for the gmerlin semaphore problem. I really think serious OSX port needs some maintainer, I cant do it, I dont have a mac, neither do I want to do it. Just occational crosscompiling and having someone who tells "It works for me" is not the way to to go. We just waiting until someone shows up to take that job (as well, i saied nicholas might do it, but he seems to be busy this days too). > > - Configuring a socket such that writing when the other end disconnected > returns an error instead of a SIGPIPE is done differently on Linux and > OSX. Not sure if there is an official Posix was to do this. > > The corresponding configure checks and a BSD-licensed semaphore > implementation are in the gmerlin(-avdecoder) trees. > > Burkhard > > _______________________________________________ > Lumiera mailing list > Lumiera@... > http://lists.lumiera.org/cgi-bin/mailman/listinfo/lumiera
Hi all, just wondering when the next Lumiera dev meeting will take place.... Seemingly we overlooked to agree on a schedule last time, or did I miss something? Anyway, taking into account that Joel stated lately that about middle of the second week will work better for him, my proposal would be Wednesday Dec 10, 2008 20:00 UTC Would this be an acceptable schedule? Cheers, Hermann
Ichthyostega wrote: > > Hi all, > > just wondering when the next Lumiera dev meeting will take place.... > Seemingly we overlooked to agree on a schedule last time, or did I miss something? > > Anyway, taking into account that Joel stated lately that about middle of the second > week will work better for him, my proposal would be Wednesday Dec 10, 2008 20:00 UTC > > Would this be an acceptable schedule? ok for me Christian
Hi, Christian Thaeter schrieb: >> - Posix semaphores are not implemented. The functions are there but >> always return an error > I try to avoid semaphores anyways, prefering mutexes (they are faster on > linux, have more sane semantic). Note that there is a option to posix > mutexes that make them shared over processes, iirc thats not implemented > in linux/glibc, but maybe it helps you for the gmerlin semaphore problem. The semaphores are not shared among processes. Also, there is no problem, because my replacement implementation (1 semaphore == 1 mutex + 1 condition variable) works perfectly. Burkhard
Hermann wrote: > Yes, agreed, Lumiera should provide some integration with Ardour, as > the latter > without doubt is "the" free DAW. This is far from being trivial, > because you > typically want to re-import your audio work and ideally you want the > additional > sound samples to align accordingly, even if the editor has done some > fine tuning > work on the cuts while the sound engineer / sound designer did his > work in parallel. > I don't know if this is possible in a completely generic fashion, but > we may exploit > the attachment and placement possibilities of the Lumiera editing > subsystem to get > such a behaviour, at least partially. Maybe adding the ability of wiring the audio tracks through Jack would be an option for that. It can be an optional configuration that would make possible to connect Lumiera with Ardour (and with other audio tools) and synchronize their data. I'm thinking about Ardour and Hydrogen, for instance, and how you can trigger an hydrogen track using Jack. I guess it would be possible to link the Lumiera's audio tracks with Ardour tracks and use the ardour's transport to triger the Lumieras play head, and that would allow to edit audio in ardour previewing video in Lumiera. Unfortunately I haven't coding skills and can't help further than making these suggestions. I ignore the complexity of this (and I'm sure this is not a trivial work), but it sounds less complicated than creating a new audio mixing system from scratch. > > Regarding your statement concerning "time and developers efforts for > creating a > good audio editor" I should add: basically our engine needs to support > playback of > quality audio and, alongside of the support for the most common video > plugin systems, > we'll have to care to support the most common audio plugin systems as > well. This is > effort we simply can't avoid. And, we'll have sidechains, meta-clips > and simliar > advanced wiring techniques for video, so probably we'll support those > for audio too. > It's even not completely off-focus to have basic support for a MIDI > datatype at some > point in the future. But you are certainly right inasmuch we don't > focus especially > on an audio production workflow. There are dedicated applications for > recording, > synthesis and playing music which far better suit this specific > purpose. Yes, that was I meant. I was talking about things that go beyond the simple audio placing, trimming and simple audio transitions (like fades or crossfades) needed in a basic audiovisual edition. I think it would be nice to start with the simple, imperative functions and (in the case of audio) leaving more complex things to more specialized packages. At least until the main requirements of video editing are fulfilled. In UI terms, it would allow to keep the complexity at the minimum. For instance, the Lumiera's preferences would allow to wire audio tracks to Ardour using jack, and once that is configured, a button for "advanced audio editing" in the main interface would perform the connections and launch Ardour. I bet it isn't easy, but it would certainly rockI keep talking to Adobe CS' users and one of the most important features they highlight in that software suite is the high degree of integration between applications. Since Ardour is THE free DAW and Lumiera's intention is to be THE free NLE, it would be great if they "talk" each other and can be used together for boosting their possibilities. It doesn't make sense to duplicate efforts if things are already done in other packages (and specially if the other application is better suited for the task). In a future it would be great too to see GIMP and Inkscape (and other free packages too) to communicate between them and bring a whole free software workflow for artistic creation. That's a wish at the moment, but I don't think it's unreachable.
| Hello guys, Has the winner been decided upon? If not, when will we commence voting? My money's with Marci's submission! lol. Take care, Sean Burns CTO, Lucid SFX Development www.lucidsfx.com |
_______________________________________________ Lumiera mailing list Lumiera@... http://lists.lumiera.org/cgi-bin/mailman/listinfo/lumiera
> Hi all, > > just wondering when the next Lumiera dev meeting will take place.... > Seemingly we overlooked to agree on a schedule last time, or did I miss something? > > Anyway, taking into account that Joel stated lately that about middle of the second > week will work better for him, my proposal would be Wednesday Dec 10, 2008 20:00 UTC > > Would this be an acceptable schedule? > > Cheers, > Hermann > > > Should be possible, Serge
RSS Feed9 | |
|---|---|
11 | |
15 | |
22 | |
69 | |
14 | |
29 | |
14 | |
22 | |
16 | |
45 | |
81 | |
74 | |
5 | |
42 | |
22 | |
52 | |
16 | |
40 | |
107 | |
48 | |
57 | |
54 | |
19 | |
56 | |
140 | |
46 | |
37 | |
18 | |
65 | |
37 | |
53 | |
198 | |
135 | |
99 | |
45 | |
129 | |
227 | |
98 | |
77 | |
152 | |
56 |
