On Sat, 2007-08-25 at 10:41 +0800, Martin Ellison wrote:
> But anyway, what is wrong with switches?
You find out soon enough if you've got a big switch in a tight
time-critical loop.
___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.l
I don't really know where the reducing quality bit came from, because
that's not what I was talking about 'tall. I was talking about 24 frame
per second second progressive footage, which hasn't anything to do with
technical quality.
-=Derek
P.S. Good idea, this new thread. A bit off topic the
Interesting idea, reducing quality as an artistic effect. I suppose some
people indeed might want it, so we could make it an option. Not for me
though.
On 25/08/07, Derek McTavish Mounce <[EMAIL PROTECTED]> wrote:
>
> I'm know, I'm brining this thread monstrously off topic, but there are a
> few m
Hopefully, you just need FICL running in its own thread.
On 25/08/07, David McNab <[EMAIL PROTECTED]> wrote:
>
> On Fri, 2007-08-24 at 22:36 +, Mark Carter wrote:
> > Not to mention the fact that threads scare me bigtime. From what I've
> > heard, I'm right to be scared.
>
> Threads are like c
C and C++ are almost convertible, in that in C++ one can write
myPicture->colourBalance(rValue, gValue, bValue); // random example
while in C one would write
colourBalance(myPicture, rValue, gValue, bValue);
which is also good C++. Most interface things can be translated in this way.
The o
On Fri, 2007-08-24 at 22:36 +, Mark Carter wrote:
> Not to mention the fact that threads scare me bigtime. From what I've
> heard, I'm right to be scared.
Threads are like cars. Incredibly handy, even life-saving if used right,
but potentially devastating if not respected.
FICL has excellent
Not to mention the fact that threads scare me bigtime. From what I've heard,
I'm right to be scared.
A separate window is a logical idea, with an "eval on enter" handler. Don't
forget, though, that you can't guarantee how long a word takes to execute. It
could load other files, and conceivably
I'm know, I'm brining this thread monstrously off topic, but there are a
few more things I need to respond to... :)
> To me, the "distance" theory sounds too much like rationalisation.
Think about it this way: The smooth motion of 50hz and 60hz is far closer
to what our eyes see in reality, so w
Herman Robak wrote:
> On Fri, 24 Aug 2007 21:58:55 +0200, Derek McTavish Mounce
> <[EMAIL PROTECTED]> wrote:
>
>> Forgot this. More of a question on what you mean exactly:
>>
>>> An NLE that deals
>>> with TV material (not just cinematic stuff) ought to be able to
>>> preserve interlacing through
On Sat, 2007-08-25 at 09:42 +1200, David McNab wrote:
> In a multi-thread environment such as Cin, you have to change from the
> 'read/eval loop' to an 'eval-on-Enter handler'.
Oh, I forgot to mention - FICL supports this perfectly. It has a
function to evaluate an arbitrary text command.
Cheers
On Fri, 2007-08-24 at 21:09 +, Mark Carter wrote:
> 24.3 Invoking the FICL REPL
> “REPL” is the read-eval-print-loop, which allows you to interact with
> Cinelerra from the console. To start the REPL, select menu item File >
> Ficl Repl. This will cause Cinelerra to “freeze” as it drops down t
On Fri, 24 Aug 2007 21:41:57 +0200, Derek McTavish Mounce
<[EMAIL PROTECTED]> wrote:
I think you are writing from a user's perspective. From the user's
perspective, Cinelerra is "almost there". I agree. In terms of
features, Cinelerra is near-complete. Or so it seems, at least.
True
Seeings as people have expressed an interest in getting scripting going, I have
put together some documentation explaining what it's all about. The
documentation is actually in my master branch - but I have reproduced chapter
24 so that you know what's going on.
24. FICL
FICL (Forth Inspired
On Fri, 24 Aug 2007 21:58:55 +0200, Derek McTavish Mounce
<[EMAIL PROTECTED]> wrote:
Forgot this. More of a question on what you mean exactly:
An NLE that deals
with TV material (not just cinematic stuff) ought to be able to
preserve interlacing throughout the workflow, no matter how many
e
Forgot this. More of a question on what you mean exactly:
>An NLE that deals
>with TV material (not just cinematic stuff) ought to be able to
>preserve interlacing throughout the workflow, no matter how many
>effects or transformations you throw in.
It is absolutely not possible to apply a trans
> I think you are writing from a user's perspective. From the user's
> perspective, Cinelerra is "almost there". I agree. In terms of features,
> Cinelerra is near-complete. Or so it seems, at least.
True enough, user I am. Though I have enough experience in programming to
be at least sligh
Hey! Valentina!! Nice to hear from you! I am glad you use this mailing
list! And I am glad that the report served for something!! Compiling
applications sometimes can be hard for "simple users" like me ;) Anyway
I am going to try to compile it myself, for learning shake!! and see if
I can serve as
Yes, I have the latest SVN .. I will send you the output later today
(now I cannot do that)or tomorrow. Thanks for your help!
I am loving this mailing list!
On Fri, 2007-08-24 at 11:05 +1200, Edouard Chalaron wrote:
> Daniel
>
> I suggest we take it out of the list for debugging, then we
Mark Carter schrieb:
> Nah ;)
>
> C++ couples functions and data, C decouples them. And decoupling rocks.
> At least that's what the adverts say.
>
> Also - and I've seen this before on a different project - if you're
> doing something like handling different classes of say, file readers, in
> C+
Hi again,
sorry again for late reply,
> hi
>
> On 8/20/07, Camille Harang <[EMAIL PROTECTED]> wrote:
>>
>> Hello,
>>
>> i feel very sorry for late reply, we was in deep Indian country-side
>> without Internet connection, then travelling around Asia but too
>> exhausted
>> to do any extra activiti
can't agree more, thanks for pointing this out, Herman!
Herman Robak schrieb:
>
> If you are going to question a _developer's_ rationale for rewriting the
> progam from scratch, you have to get a feel on how developing Cinelerra is.
...
> Interlacing is not going away soon.
...
> And 50Hz inte
Please forgive me me butting in - I lurk on this group a lot but don't often
have much to contribute. This time, though:
I have been using Python a lot recently. I think you might benefit from
using something like this in the UI. We have some stuff where Python uses
GNU Make. Make, being compi
It seems that the Schemes and Lisps of this world have never really go their
act together. I'm watching the SICP videos, and they really turn you on to just
how powerful something like Scheme is. I myself am not a Schemer or Lisper, it
just ends up too painful.
I saw something on the internet a
On Fri, 24 Aug 2007, Mark Carter wrote:
> It would be nice to use a really high programming language, but we live
> in a C world.
I totally agree on this point. But that same language must beable to be
compiled into binaries. Because it is not a C world, it is a x86(-64)
instructionset world. (Al
On Fri, 2007-08-24 at 10:14 +, Mark Carter wrote:
> And that's why I still don't buy your argument about C++ being
> intrinsically superior.
I don't feel that C++ per se is intrinsically superior. It's just that
its OO is the best of an abysmal bunch.
I personally prefer 'C with basic OO'.
C
Well, I don't really want to get into an argument about it - but I still don't
really agree. "Maybe", but I'm still not convinced. Just because MS Windows API
is flawed doesn't mean that C is flawed (and I'm not saying that C isn't
flawed) - it just means that the Windows programmers came up wit
hi,
i'm debian user, snip! so i did make ubuntu packaging but really never
use them.i'll have a look at machine i used to compile ubuntu :D
thx for report!!!
Vale
Before I start I would introduce myself: I am new to Cinelerra and
relatively new to linux (a newbie), so do not slaughter
On Fri, 2007-08-24 at 08:15 +, Mark Carter wrote:
> Nah ;)
>
> C++ couples functions and data, C decouples them. And decoupling
> rocks. At least that's what the adverts say.
Coupling can be bliss or nightmare.
At its best, it can sort C spaghetti into organised looms.
At its worst, it can cr
Nah ;)
C++ couples functions and data, C decouples them. And decoupling rocks. At
least that's what the adverts say.
Also - and I've seen this before on a different project - if you're doing
something like handling different classes of say, file readers, in C++ you have
to resort to a lot of s
The last time I checked, C++ had stricter type checking. But yes, I am
recommending a C-style interface.
On 24/08/07, David McNab <[EMAIL PROTECTED]> wrote:
>
> On Fri, 2007-08-24 at 12:41 +0800, Martin Ellison wrote:
> > C and C++ have a large common subset; perhaps you could use that.
>
> Haha,
30 matches
Mail list logo
