Hi all,
I just thought some you you might be interested in how a small mnority
of the MacOSX world sees the fruits of our hard work.
Regards,
Erik
Begin forwarded message:
Date: Sun, 26 Oct 2003 18:20:39 +1100
From: Erik de Castro Lopo <nospam(a)mega-nerd.com>
To: undisclosed-recipients: ;
Newsgroups: comp.sys.mac.apps,gnu.misc.discuss
Subject: Open letter to Steve Dekorte
Dear Mr Dekorte,
This has been emailed directly to you as well as being posted to
Usenet in the groups gnu.misc.discuss and comp.sys.mac.apps.
I am writing to you in regard to your shareware application for
MacOSX available here:
http://www.dekorte.com/Software/OSX/SoundConverter/
Please also note that I am not charging you with contravening
anyone's software license. I am however charging you with
behaviour that is both morally repugnant and deceitful.
When I download the tarball you provide (for which you charge
US$10 for a full license) I find the following files:
SoundConverter.app/Contents/Resources/ffmpeg
SoundConverter.app/Contents/Resources/macconverter
SoundConverter.app/Contents/Resources/mppdec
SoundConverter.app/Contents/Resources/qt_export
SoundConverter.app/Contents/Resources/ringtonetools
SoundConverter.app/Contents/Resources/scm2wav
SoundConverter.app/Contents/Resources/sndfile-convert
SoundConverter.app/Contents/Resources/sox
Here is some information about these programs:
Program Size Author Licence
--------------------------------------------------------------
ffmpeg 1.46M Fabrice Bellard LGPL
macconverter 17k ? ?
mppdec 85k Frank Klemm GPL
qt_export 56k David Van Brink Lootware???
ringtonetools 94k Michael Kohn Non-comm. use only
scm2wav 15k Christoph Leuzinger MIT License
sndfile-convert 795k Erik de Castro Lopo GPL/LGPL
sox 3.12M various LGPL
Now compare this with the only part of this tarball actually
written by you, the SoundConverter binary which weighs in at
399k.
From the looks of this, your contribution to the total is
significantly less than 10%. I would also argue that your
contribution (a couple of hours with the MacOSX GUI builder)
is far less that the amount of time and effort put in by the
other people whose work you are using.
How can you possibly justify pocketing US$10 per license for
work to which you have contributed well less than 10% of the
total time and effort.
Furthermore, on the web site listed above, you display a credit
for the guy who designed the icon, while none of the people who
wrote the actual code get any credit whatsoever. Interestingly,
many of the licenses above (GPL, LGPL, MIT etc) were developed
to foster openness in the field of software development, much
like the openness of scientific research. In scientific research
circles, it is considered important to credit the people whose
work yours builds on. In this case, you have failed miserably
to do so. If you were a researcher you would be charged with
academic misconduct and fraud.
Now many people might think that you are just doing what Redhat,
Suse and the other Linux distributors are doing; bundling up
other people's software and selling it. However, I see a big
difference. Redhat and Suse make huge contributions to the Free
Software world; Redhat supporting GCC and GNU libc and Suse
suporting KDE and ALSA.
In light of all this, I am curious to know, what is your
contribution? If you aren't contributing I suggest that you
take all three of following three:
a) Immediately, release the source code to SoundConverter
under a suitable free license.
b) Donate all the money you have collected so far to the
Free Software Foundation or a recognised charity of your
choice.
c) Add some credits on your webpage to the people who did
the vast majority of the work.
I look forward to reading your response in one of the above
public newsgroups.
Regards,
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo nospam(a)mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"He who writes the code gets to choose his license, and nobody
else gets to complain" -- Linus Torvalds
New Yorkers for Fair Use Action Alert:
--------------------------------------
Please send a comment to the FCC AGAIN, opposing the "Broadcast Flag"
Proposal
Tell the FCC to Serve the Public, Not Hollywood!
Okay, you folks understand this issue -- it's very important to send word to
the FCC in the next few days, that you OPPOSE the Notice of Proposed
Rulemaking #02-230. This rule would make it illegal for ordinary citizens
to own fully functional digital television devices. We've made it easy;
just follow the links below.
1) Please send in your comments to the FCC using the form provided below.
Tell them that the movie industry should not have a special privilege to own
fully-functional digital television devices. Read the alert below for
details.
2) Please forward this alert to any other interested parties that you know
of, who would understand and see the importance of this issue.
3) Volunteer to help us with this and other alerts related to your rights to
flexible information technology in the future. Two roles you can take up
are to become a Press Outreach Campaigner or a Commentator. Simply reply to
this email to show your interest.
New Yorkers for Fair Use Action Alert:
--------------------------------------
Tell the FCC to Serve the Public, Not Hollywood!
Send Public Comments to the FCC AGAIN to Stop the "Broadcast Flag"
Please follow these links to let the FCC know that the public's rights are
at stake:
http://www.nyfairuse.org/action/fcc.flag/
What's Going On:
The FCC is expected to decide this week that digital televisions will be
required to work only according to the rules set by Hollywood, through the
use of a "broadcast flag" assigned to digital TV broadcasts.
As a result of the deliberations of a group called the Broadcast Protection
Discussion Group, which has assiduously discounted the public's rights to
use flexible information technology, Hollywood and leading technology
players have devised a plan that would only allow "professionals" to have
fully-functional devices for processing digital broadcast materials.
Almost a year ago, you responded to our call to tell the FCC that they are
to serve the public, not Hollywood. You delivered more than 4000 comments
to the the FCC's public comments system in the space of the last week of
their public comments period for the broadcast flag proposal. As a result
of this, Congress took notice and called a hearing to question the FCC on
the issue. When they asked the FCC's representative whether he believed
they could make this copyright-related policy decision without stepping
beyond their bounds and into Congress's jurisdiction, they answered in one
word: "Yes."
Now, their period of considering the proposal is drawing to an end, and they
are expected to decide to mandate the broadcast flag in a matter of days, by
the end of this month. It's time to demonstrate AGAIN that the public's
interests take priority over the wishes of the MPAA.
The idea of the broadcast flag is to implement universal content control and
abolish the right of free citizens to own effective tools for employing
digital content in useful ways. Hollywood and content producers must not be
allowed to determine the rights of the public to use flexible information
technology. The broadcast flag is theft.
In the ongoing fight with old world content industries, the most essential
rights and interests in a free society are those of the public. Free
citizens are not mere consumers; they are not a separate group from
so-called "professionals." The stakeholders in a truly just information
policy in a free society are the public, not those who would reserve special
rights to control public uses of information technology.
Please let the FCC know that the public's rights are at stake:
http://www.nyfairuse.org/action/fcc.flag/.
Here is a page pulling together and summarizing the comments submitted after
the last comments campaign:
http://www.nyfairuse.org/bfpc/
Here is our Reply Comment:
http://www.nyfairuse.org/bfpc/extdoc/NPRM%2002-231%20Reply%20Comments.pdf
----
The following link is the FCC's "Notice of Proposed Rulemaking" for the
broadcast flag.
http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-02-231A1.pdf
Hi all, I've tried contacting the maintainer of the project (Andy), but
he never bothered to reply, so now I am taking this question to all of
you out there that might have had exposure to this interesting library.
Does anyone know what is the current status of the whole project anyhow?
Any help on this matter is greatly appreciated! When answering any of
the given questions, please include the question in your reply. Thank
you very much!
So here's the excerpt from the letter:
I've recently decided to incorporate libalsaplayer-like functionality
the upcoming version of my app RTMix. However, with having a particular
feature in mind I am wondering whether libalsaplayer provides that and
if not, whether you'd be willing to add it (or let me add it, although
that might get messy since I am not too familiar with the inner workings
of the lib). So, here it goes:
Apart from all the wonderful features libalsaplayer offers, I am looking
for some additional ones:
I would like to be able to indefinitely loop specific "ranges" of a
particular soundfile (i.e. 2.2secs-4.12secs or whatever).
1. Is it possible to do this and have music continually loop even if one
changes the direction of playing so that when the alsaplayer runs out of
the looping material in each direction that it just jumps back onto the
other end of the loop and contiues on (kind of like a ring-buffer)?
2. Is it also possible to do this kind of looping on the whole soundfile
(the gui version of alsaplayer always stops if I let it play 'til the
end or the beginning, depending in which direction I am going).
3. Is it possible to define loop points by addressing a particular
sample number rather than giving time in seconds?
4. How stable is alsaplayer when looping really small chunks of sound
(i.e. like 5 sample loop)?
5. Is alsaplayer capable of ramping such loop points by attenuating
let's say ending 20 samples (it would be cool if this number could be
user-selectable) and then ramping up the beginning 20 samples in order
to alleviate the "pop" that happens when looping a sound where waveforms
at the beginning and the end do not align?
6. If the feature in question 5 does not exist is there a way to control
output level of a player on a per-sample basis via callback so that one
can implement that outside of the lib?
7. If neither 5 or 6 are possible, would you be willing to implement
such functionality (i.e. a toggle_ramp( bool ); and set_ramp_length( int
); callbacks or something similar.
I would greatly appreciate your feedback on this matter as that will
greatly assist me in determining how to go about implementing such
functionality in my app.
Thank you very much! Looking forward to hearing from you. Sincerely,
Ivica Ico Bukvic, composer & multimedia sculptor
http://meowing.ccm.uc.edu/~ico
P.S. How do you implement reading of a sound faster and slower than it
sounds in such a gradual fashion? Do you adjust the sampling rate of the
DSP and if so does that affect other streams coming from the
libalsaplayer, or is this something that is sound-specific (and if so,
how)?
Just a FYI. Those of you on ardour-dev will have parts of this list in
various "latest CVS commit" messages. People using old versions of
ardour should update. This new beta has lots of great stuff, with more
to come. The new Mantis bug reporting/tracking system is making life
way better for everyone.
--p
----------------------------------------------------------------------
* additions/updates to AUTHORS
* point people at ardour.sf.net/mantis for bug reporting
* new region selection model
- button1 press always selects
- shift-button1 press adds an unselected region,
unselects a selected region
- more comfortable "selected region" color
* new align_selection and align_relative commands
* alignment now uses edit cursor
* new commands to move playhead + edit cursor
to region starts, ends and sync points
* new zoom control interface, permitting arbitrary zoom
levels (not just power-of-2)
* new "add track/bus" dialog, allowing N to be added
at once
* mixer meters now support metering to +6dB, with new
pixmap so that only >0dB is red.
* initial implementation of 2-stage "clean up unusued audio files"
* fix for transport lockup
* fix for crashing bug when exporting at non-session frame rate
* better functionality when editing AudioClocks
* removed musical (BBT) time from Selection model
* snap to region start/end/sync
* snap to edit cursor
* avoid neon when picking new colors
* new transport pixmaps that are theme/skin resistant
* tempo/measure lines now extend past end of session
* hide editor mixer strip when clicking on current mixer track
* brush mode works again ("paint" a region onto snap points)
* added back "embed" functionality for referring to external
soundfiles without importing
* scroll playhead or edit cursors in the timeline rulers
* check all X keyboard modifiers at startup, warn about duplicates
* fixed crashing bug when marker was removed
* allowed command-line specification of JACK client name
* fixed mouse drags of torn off windows
* code cleanup and redesign
Hi all,
LADCCA's now reached a state where I reckon it's worth releasing again.
It's pretty stable for me, and it now seems to do what it should without
any hiccups. I'm releasing alsa patch bay and jack rack along with it
as the only changes are support for the new ladcca version. ALSA Patch
Bay has had 1.0-ness for a while now so I'm taking the opportunity to
bump the version. There's only two other supported apps at the moment,
muse, which already has 0.4.0 support in cvs and fluidsynth, a patch for
which is included in the tarball.
From the ladcca NEWS file:
* low level tcp protocol has changed along with a lot of structure clean
ups on the client- and server-side.
* added low level protocol versioning
* well defined server interface protocol (that works! :) this has been
the bulk of the work that's added two more properties to cca_event_t,
client_id and project, bumped the major version of the high level
protocol and caused more changes to the low level protocol
* new high level normal client event, CCA_Server_Lost
* removed CCA_Use_Jack and CCA_Use_Alsa client flags; sending the server
the jack client name or alsa client id now suffices
* major amounts of cleanups and fixes
* server now saves project info in XML which means a new dependency on
libxml2
* socket stuff now uses protocol-agnostic system calls and the server
defaults to IPv6. an entry in /etc/services is required to support
this. make install will install an entry if there isn't one present.
this can be disabled with a configure option, --disable-serv-inst.
there's also a new option for ladccad, --no-ipv6 which, suprisingly,
stops the server using ipv6.
* the --with-default-dir configure option and -d ladccad option now set
the directory relative to $HOME, rather than being a system-wide
directory
* project directories now get cleaned up if they haven't been saved
* updated the manual
Patches
* fluidsynth cvs
http://pkl.net/~node/ladcca.htmlhttp://pkl.net/~node/alsa-patch-bay.htmlhttp://pkl.net/~node/jack-rack.html
Bob
--
Bob Ham <rah(a)bash.sh>
"At some point, keystroke recorders got installed on several machines at
Valve. Our speculation is that these were done via a buffer overflow in
Outlook's preview pane." -- Gabe Newell on the Half-Life 2 source leak
1)is API monolithous or there are sub-APIs
like GMPI-audio, GMPI-seq, GMPI-control
2) Explicit versioning for API?
3) Explicit versioning for plugins?
4) uniq IDs for plugins?
who is authority?
5) format for plugin state saving:
XML? (damn its ugly!)
I vote for more YAML-like language.
6) Should the GMPI discussion produce
reference plugin implementation
reference host implementation
reference tools implementation
7) Can there be off-line non real-time plugins?
8) Should the specification produce
any requirement for more documents?
For example:
A documant describing standard set of plugins
(like in General Midi) so one could expect
the first 64 plugins to be so and so.
horsh
Well it's just requirements?
Then what about :
1) jack-transport-like and
2) LADCCA-like functionality?
the requirement resolution could sound as:
"GMPI does not need such functionality",
but if it souns as "GMPI _does_ need..."
then it would be very welcome.
horsh
====================8<==========================
One of my tasks as part of GMPI is to provide a draft of the requirements
doc. I turn tp you all. If you have requirements that you think should be
in GMPI - please let me know. These have to be requirements. Not
handwaving though explosions, and not wishful dreaming. Things that are
required or desired that will make GMPI be the open music platform we need.
Feel free to email me privately or publicly. I'll be happy to condense
ideas and to extract requirements from whatever you have for me.
Trying to get the ball rolling again...
Tim