2008/1/19, Fred Williams <fred(a)fredwilliams.ca>:
> Fine a wiki for the developers and a web site are good ideas.
> Developers may come and go and getting them up to speed on the project
> requires documentation and possibly training. Internal communications
> is vital and every developer should be in almost constant contact with
> the group to make sure everybody's on the same project and knows what is
> going on. This synergistic culture is vital to such a team. It's in
> everybody's interest that all the other team members understand the
> project perfectly. Time spent bringing a new member up to speed is not
> wasted. A developer's bulletin board is essential. Well defined
> standard interfaces for code is also essential and design changes must
> be tracked and approved by the core development team. Things like that
> ensure a solid program.
> I could get behind a project like that.
Ok, so what needs to be done to get such a project rolling?
The following is my opinion, and of course everyone is free to argue
otherwise. ;-)
When "planning" a project, I prefer to make an Assessment of the
resources that I have available first, because I somehow like to be
realistic about what really "can" be done instead of building castles
out of air and then being disappointed that it did not work out.
So, this "Project" seems to be about "Code", programming code and
such. So, while there is certainly a lot of code already out there
that can be reused, someone has to fit it together and someone has to
fill in the missing parts. So this project will involve coding. So we
need "Coders". This is how open source projects work, they need
coders. There are many people with ideas, but someone has to code it
and generally, those people are a scarce resource.
So, in planning this stuff the first thing to find out is who are the
coders, and what are they willing to do. Making big plans and then
expecting outsiders to jump in and start coding is an approach that
has proven not to work, at least as far as my experience goes.
Maybe at one point outsiders will come and start contributing, but for
that to happen, a solid core is needed, something that is of value to
contributors.
And btw. I also believe that making plans that reach too far into the
future are very, very risky, especially if one relies on volunteers.
Better make a small proposal for a well defined problem, for which a
solution is immediatly useful. Then try to get it solved as fast as
possible, before people loose interest, and then try to "infect" as
many peer groups as possible with the solution to create an
"eco-system" where the solution can sustain itself.
Then fit that part into the big picture, and move on to the next
little puzzle part.
So, I am volunteering to do stuff, who else is?
Cheers
-Richard
PS.: the discussion is distributed among the following mailinglist, so
check the archives:
https://www.bek.no/mailman/listinfo/pikselhttp://lists.linuxaudio.org/mailman/listinfo/linux-audio-devhttps://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
--
Are you teaching the What and the How but without the Why and the When?
This looks like an opportunity to beef up audio side of things as well as
foster development of another powerful foss multimedia software.
See below for more info.
Best wishes,
Ivica Ico Bukvic, D.M.A.
Director, Linuxaudio.org
Virginia Tech
Dept. of Music - 0240
Blacksburg, VA 24061
(540) 231-6139
(540) 231-5034 (fax)
ico(a)linuxaudio.org
www.linuxadio.org
-----Original Message-----
From: piksel-bounces(a)bek.no [mailto:piksel-bounces@bek.no] On Behalf Of
Fabianne Balvedi
Sent: Friday, January 18, 2008 7:05 PM
To: p1k53l workshop
Subject: [piksel] Fwd: [estudiolivre] I believe in cinelerra
---------- Forwarded message ----------
From: Leo germani <leogermani(a)gmail.com>
Date: Jan 18, 2008 7:53 PM
Subject: [estudiolivre] I believe in cinelerra
To: estudiolivre <estudiolivre(a)lists.riseup.net>, Felipe Fonseca
<felipefonseca(a)gmail.com>
What
Develop cinelerra as a professional free/libre video editing tool.
Why
Cinelerra is the most powerfull free software for video editting we
have nowadays. Although it has many resources and that it is far more
advanced than any other Open Source video software, its development is
very slow and has no sponsor.
Its main developer, Heroine Warrior, do not mantain a SVN or a mailing
list. The last official release was last july and there is no sign of
a upcoming version of cinelerra. They usually publish a new release
every six month or so but do it only for their own needs and do not
talk with the community much.
Few developers mantain a fork called "Community Version". All out of
volunteer work they mantain a SV a mailing list and an online wiki.
They also fix some bugs and add some features to the code.
This desorganized development results in a mess. There is no official
stable release and package for the distributions, and cinelerra is now
known as very hard to install and unstable software (although it got
really better last year).
Also, first contact with cinelerra is usually disappointing because of
a not well resolved interface and also because of big flaws it has on
some funcionalities.
With all that said, it happens that we have a software that is, at the
same time, powerfull enough to do any kind of editing, but weak enough
to have very basic issues of usability.
And the feeling all advanced users have is: We are pretty close to
have high standard software!
To learn more about the mess, take a look at this page:
http://cv.cinelerra.org/about.php
Many of the actions described on this plan are already been done by
many people, but in a rather heroic way. If this people got motivated,
organized and _paid_, cinelerra would increase its quality
dramatically in a short period of time.
The Plan
1. Get the community together
The community of developers today is very small and spread, and
cinelerra has no road map.
First thing to do is gather this people to discuss about the future of
cinelerra, identify the main flaws and its solution, make a plan to
organize the place and set up for new features.
Cinelerra needs a project leader, an interface designer, and more
people with defined roles that should be choosen on this meeting.
Developers of other softwares are also welcome. Cinelerra is, so far,
the only video free editing video editing software with professional
approach, but it could share a lot of things with other software, such
as effects, for example, that shoul be usable in any video software,
just like we have LADSPA for audio. There is already a video effect
standar called Frei0r that cinelerra does not support.
2. Diagnostics
Cinelerra code is not very well documented, so few people have the
idea of how tuff is to deal with it. Second step is to see what must
be done so we can invite more people to colaborate with the code.
Documentation, refactoring, etc. It also has to work on the API so
other people can write plugins and effects.
In other words, lots of work that are a pain in the ass but has to be
done in order to advance properly. And passion has a limit. There must
be people getting money to work on that.
3. Make a plan
Based on the diagnostics and on researches with users and other video
editing tools, define how cinelerra will look and act in a not so
distant future. With that goal in mind, make a reasonable plan to make
it happen.
3. Set up a core development team
No secret here. Few people dedicated to make it happen, including an
interface designer.
4. Bounties
The core team can offer bounties for parts of the job they choose.
This will attracat more developers to the community.
5. Attract contributors
Mantain a nice looking website, a wiki, tools for easy translation of
the interface and of the online documentation, etc. are goos
strategies to attract people to contribute. Its also important to find
people to package the software for different distributions.
--
leogermani.pirex.com.br
leogermani.estudiolivre.org
________________________________
Lista de Discussão do Estúdio Livre
portal colaborativo -> http://www.estudiolivre.org/
sobre esta lista -> http://lists.riseup.net/www/info/estudiolivre
--
Fabianne Balvedi
GNU User #286985
http://fabs.estudiolivre.org
"As contradições mais agudas da vida humana
não foram feitas para serem solucionadas, mas vividas
com plena ciência de seu carater paradoxal."
Isma'il Al-Faruqi
_______________________________________________
piksel mailing list
piksel(a)bek.no
https://www.bek.no/mailman/listinfo/pikselhttp://www.piksel.no
Greetings,
I'm trying to get IRCAM's Open Music 5.2.1 running here, but I'm having
various difficulties. For now, I'll focus on this one: I'm trying to
build MidiShare (it's required by OM) on my 64-bit machine (64Studio),
and I've got this far :
make -C kernel
make[1]: Entering directory
`/home/dlphilp/src/openmusic/midishare-1.91-linux2.6-src/src/linux/kernel'
for x in atomic/lffifoIntel.c atomic/lflifoIntel.c Clients/msAlarms.c
Clients/msAppls.c Clients/msConnx.c Clients/msFilter.c Clients/msMail.c
Clients/msTasks.c Clients/msXmtRcv.c Kernel/msHandler.c Kernel/msInit.c
Kernel/msSmpte.c Kernel/msTime.c Memory/msEvents.c Memory/msFields.c
Memory/msMemory.c Memory/msSeq.c Sorter/msSorter.c Drivers/msDriver.c;
do ln -sf ../../common/$x `basename $x`; done
make modules -C /usr/src/linux
SUBDIRS=/home/dlphilp/src/openmusic/midishare-1.91-linux2.6-src/src/linux/kernel
make[2]: Entering directory
`/usr/src/linux-headers-2.6.21-1-multimedia-amd64'
CC [M]
/home/dlphilp/src/openmusic/midishare-1.91-linux2.6-src/src/linux/kernel/msLoader.o
/home/dlphilp/src/openmusic/midishare-1.91-linux2.6-src/src/linux/kernel/msLoader.c:1:
sorry, unimplemented: code model kernel not supported in PIC mode
/home/dlphilp/src/openmusic/midishare-1.91-linux2.6-src/src/linux/kernel/msLoader.c:1:
error: code model ‘kernel’ not supported in the 64 bit mode
make[3]: ***
[/home/dlphilp/src/openmusic/midishare-1.91-linux2.6-src/src/linux/kernel/msLoader.o]
Error 1
make[2]: ***
[_module_/home/dlphilp/src/openmusic/midishare-1.91-linux2.6-src/src/linux/kernel]
Error 2
make[2]: Leaving directory
`/usr/src/linux-headers-2.6.21-1-multimedia-amd64'
make[1]: *** [all] Error 2
make[1]: Leaving directory
`/home/dlphilp/src/openmusic/midishare-1.91-linux2.6-src/src/linux/kernel'
make: *** [kernel] Error 2
Has anyone ever compiled MidiShare for a 64-bit machine, and if so, how
? I'm using Albert Graef's patches for MidiShare 1.91, but they don't
address the 64-bit problem. Is MidiShare even maintained anymore ? I had
troubles compiling 1.91 on my 32-bit box too, and since it's required
for Open Music I'd like to figure out how to build it on both boxes here.
Some time ago I did write to GRAME re: MidiShare development but
received no response.
Any suggestions ?
Best,
dp
Lars Luthman wrote:
> On Mon, 2008-01-14 at 20:24 +0100, Pieter Palmers wrote:
>> Dear Linux Audio users,
>>
>> A new jack release (0.109.0) is available:
>> http://sourceforge.net/project/showfiles.php?group_id=39687
>>
>> ...
>>
>> API changes:
>> * add jack_thread_wait API
>> * remove port_(un)lock functions
>> * add new time APIs
>> * add port aliases
>> * add new client registration callback
>> * add port connect callback
>
> ... and the new (since 0.107) MIDI buffer functions with the last
> nframes parameter removed, I assume?
Indeed. I forgot to mention that.
Greets,
Pieter
On Thursday 10 January 2008 12:27:13 you wrote:
> On Thursday 10 January 2008 09:00:03
>
> linux-audio-user-request(a)lists.linuxaudio.org wrote:
> > Message: 8
> > Date: Wed, 09 Jan 2008 22:50:07 +0100
> > From: Dragan Noveski <perodog(a)gmx.net>
> > Subject: Re: [LAU] [ANN] new version of ssg (Simple Sine Generator)
> > To: A list for linux audio users
> > <linux-audio-user(a)lists.linuxaudio.org>
> > Message-ID: <4785418F.9070502(a)gmx.net>
> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> >
> > Dragan Noveski wrote:
> > > Nedko Arnaudov wrote:
> > >
> > >
> > >> New version of Simple Sine Generator is available.
> > >>
> > >> It now requires lv2core.
> > >>
> > >>
> > >>
> > >
> > > hallo nedko, could you please provide us the URL to this library
> > > (lv2core)?
> > >
> > > cheers,
> > > doc
> > >
> > >
> >
> > the answer on my question just came with dave ANN - sorry for the noise!
> >
> > cheers,
> > doc
>
> I'm sorry, could someone explain the lv2core call? Download? I'm confused
> :)
Oh, Dave Robillard on the dev list, sorry.
Hi. My name is Roque Morel
NtEd is the easiest music score I`d saw.
Only three steps: ./configure, make, make install and it`s ready to use.
Rare dependencies and libraries does not need it. Where another ones
failed on my favor distro, NtEd got no any trouble.
Commands are very easy too and it works very well with Timidity or
QJackctl+QSynth.
It supports tuplets and others, up to 4 voices per staff, 5 lyrics
lines, three clefs, exports to GS and MIDI.
Very important things?
It`s a real page view music score for Linux, it`s easy for musicians, it
is not a too much MB program, it`s nice to work and the more important
point in music: it`s a What You See Is What You Get music score and is
stable.
Necessary things?
Slurs, bow signals for strings instruments, more clefs and other musical
signs.
For Mandriva`s users as me, there are some packages in cooker
repositories I asked by bugzilla
ftp://distrib-coffee.ipsl.jussieu.fr/pub/linux/MandrivaLinux/devel/cooker/cooker/media/contrib/release/nted-0.13.0-1mdv2008.1.i586.rpm
ftp://distrib-coffee.ipsl.jussieu.fr/pub/linux/MandrivaLinux/devel/cooker/x86_64/media/contrib/release/nted-0.13.0-1mdv2008.1.x86_64.rpm
Author URL:
http://vsr.informatik.tu-chemnitz.de/staff/jan/nted/nted.xhtml
downloads source:
http://vsr.informatik.tu-chemnitz.de/staff/jan/nted/nted-0.16.0.tgz
Debian packages:
http://vsr.informatik.tu-chemnitz.de/staff/jan/nted/nted-0.16.0.deb
I forgot to comment on the matter musicXML version 0.16.0
Enjoy it
Perhaps you don't know what a vocoder is, but I'm sure you have heard
one before. Vocoders are often used to add a robotic effect to vocals
in music.
Project homepage:
https://gna.org/projects/lv2vocoder
Get tarball from here:
https://gna.org/files/?group=lv2vocoder
This code is based on version 0.3 of LADSPA plugin created by Josh Green.
LADSPA plugin created by Josh Green is basically an adaption of
Achim Settelmeier's Vocoder program to LADSPA.
Achim Settelmeier's Vocoder programs and Josh Green's LADSPA plugin, can
be found at:
http://www.sirlab.de/linux/
Happy robots use Linux and LV2!
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
The zyn project main goal is to extract synth engines from ZynAddSubFX
and pack them in LV2 plugin format. Resulting plugin(s) are heavily
based on work made by Nasca Octavian Paul.
Project goals:
* Port ZynAddSubFX synth engines to LV2
* Fix some inherit issues preventing hard-realtime mode of operation,
causing clicks sometimes (memory allocation/sleep in audio process
context)
* Make synth engines reusable in source form
* Make all synth engines parameters controlable on the fly (as opposed
to original "parameter change takes effect on next note on" strategy)
Currently only zynadd (ADDsynth) is ported. Not all parameters are
exposed yet. Nevertheless plugin produces sound/noise and has enough
parameters exposed to tweak sound generation at great extent.
You need lv2dynparam plugin library to compile the plugin.
Project homepage:
http://home.gna.org/zyn/
Get tarball from here:
https://gna.org/files/?group=zyn
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
zynjacku is JACK based, GTK (2.x) host for LV2 synths. It has one JACK
MIDI input port (routed to all hosted synths) and one (two for stereo
synths) JACK audio output port per plugin. Such design provides
multi-timbral sound by running several synth plugins.
zynjacku is a nunchaku weapon for JACK audio synthesis. You have solid
parts for synthesis itself and you have flexible part that allows
synthesis to suit your needs.
You need slv2 library and lv2dynparam host library to compile zynjacku.
Project homepage:
http://home.gna.org/zynjacku/
Get tarball from here:
https://gna.org/files/?group=zynjacku
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
lv2dynparam is LV2 extension for dynamic parameters.
The extension consists of a header describing the extension interface
and libraries, one for plugins and one for hosts, to expose
functionality in more usable, from programmer point of view, interface.
Project homepage:
http://home.gna.org/lv2dynparam/
Get tarball from here:
https://gna.org/files/?group=lv2dynparam
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>