Dear Linux Audio users,
A new jack release (0.109.0) is available:
http://sourceforge.net/project/showfiles.php?group_id=39687
Enjoy,
Pieter
(Releaser-ad-interim)
Changelog
=========
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
Backends:
* ALSA: fix for use of snd_pcm_link
* ALSA: hardware jack-midi support
* ALSA: fix for enabling big-endian 16bit format discovery
* ALSA: hardware jack-midi support
* FreeBoB: fix deallocation segfault
* FireWire: add 'firewire' backend for use with FFADO
* OSS: add support for proper triggering in OSS driver when in full
duplex mode
* ALSA: fix illegal use of ALSA API
* OSS: disable software mixing and samplerate conversions on OSS 4.x
* CoreAudio: fix sample rate management
Other
* add JACK_PROMISCUOUS_SERVER handling
* make /dev/shm the default tmpdir
* add -Z flag to cancel zombification on timeout
* add per-port update total latency
* increment default watchdog timeout to 10sec
Fons Adriaensen wrote:
> Seriously, there are three things that I profoundly dislike in MIDI.
>
> 1. The limited precision of almost all values, 7 bits or 14 with a
> kludge (but even this kludge is not available in any standard
> way for e.g. individual note frequencies).
>
> 2. Note events are identified by their frequency.
>
> 3. The only thing that can actually refer back to a note on event
> is it's corresponding 'note off' message. It's not possible to
> send a controller value that refers to a previous note-on event.
I'm quite sure many of us would like to see this limitations go away,
including Dave. Being able to work with MIDI hardware is reason
enough to have MIDI sequencing. That doesn't rule out to have
something else, additionaly.
How about you work out a proposal? Or better yet a draft
implementation, as we all have seen how far one gets with talking ...
I guess you have the technical and musical expertise and maybe
the motivation thanks to your specific interests. Once you have
completed something, perhaps someone steps up to crticise it.
--
Thorsten Wilms
Phil Rhodes wrote:
> It seems to me dangerously like you're running off down a road familiar
> to Linux - create something that's a fantastic engineering solution and
> runs at a million miles an hour on a 286, but which is completely
> pointless and unusable because it won't talk to anything.
indeed, but do you have an alternative? It's sort-of a chicken-and-egg
issue. Back when jack was conceived, there were no jack clients either.
So you didn't have anything to 'talk to' either (important exception: a
soundcard).
If we can come up with something 'better than MIDI', it could be
interesting. Especially since these days a lot of audio stuff doesn't
leave the pc anyway. The only thing tying us to MIDI are the external
devices. And if the 'better than MIDI' can be downgraded to plain MIDI
you have something to talk with.
Greets,
Pieter
With the release of Jack 0.109 we now have a (hopefully)
stable API for midi-over-jack. This set me to consider what
would be required to modify Aeolus to use this system.
And I did not like the conclusions.
Is it a good idea to insert a 30-year old data format
that mixes real-time and general data on a single stream
into a real-time audio processing API ? I don't think so.
1. Note on/off and controller events now can be 'sample
accurate'. That's nice to have. But a) they are not and
never will be 'sample accurate' if they come from a HW
midi device, and b) if they are generated in software then
you can have, and for some applications you actually want
much more finer grained timestamps and controller values.
So it's a solution that in one case is plain overkill,
and in the other it's just not good enough.
2. *All* MIDI data now has to pass through the RT-audio
audio thread, even if it's not related to any RT operations
at all, and in many cases, not even meant for the receiving
application. What is the poor process callback to do with
sysex memory dumps, sample downloads, and in most cases,
even program changes ? The only thing it can do is get rid
of this ballast as fast as possible, dumping it in a buffer
to be processed by some lower-priority process, and hoping
it will not be blocked or forced to discard data. Forcing
a critical RT-thread to waste its time in this way is IMHO
not good program design, not even if the overhead can be
tolerated. That sort of data should never go there.
Some sort of solution could be to let the MIDI backend do
at least part of the filtering - it could have several
jack-midi ports corresponding to a single raw midi input
and e.g. separate note on/off, controller events, and
sysex messages. An app that wants to receive all can
still do so without any significant overhead, it just
needs a few more ports.
And once e,g. note on/off and controller updates have
dedicated ports, there is no more need to keep the MIDI
format with all its limitations.
This will be enough for some flames, so I'll stop here
:-)
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Lascia la spina, cogli la rosa.
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