>> That said, I think Patrick is right to start thinking about this now.
Thanks.
>I think he's completely right - I'm not sure about this bank account
>thing but I do think that now is the time to be demoing, talking up and
>generally approaching people and companies about Linux music software.
>I wrote us up (and mentioned a few other apps) in the latest edition of
>Linux User - John at mstation.org has been very kind so far as well.
>Now is the right time to be talking to people and getting the
>"products" out there. If it works - why not tell people about it?
The reason I believe we need to have various bank accounts are because
we cannot afford to waste money on excessive service charges and not
everyone has access to credit cards. If we have the accounts in the
right countries then people can just donate cash.
From a professional perspective we need to show our prospective clients
that we have sound financial thinking. It's mostly a subconscious need
that consumers have. They want to know that the money they are investing
is being given to people/companies/organisations who use it. Most people
don't really care how it is used although we have the moral
justification on our side too.
This is from the Sound on Sound advertising package.
"The main target market of Sound On Sound is the professional
and semi-professional musician who is the kind of person that will have
the spending ability to purchase a large range of products from
synthesizers to samplers, mixing desks to microphones, multitracks to
monitors, effects to expanders and computer hardware and software.
They are not time wasters who do not know their profession - they are
serious and mature individuals working with a reasonable budget."
If we want to appeal to this audience we need to prove to them that they
are investing in professional audio. We need to wine them and dine them
(metaphorically). If they look into our commmunity and say these are
just amateur geeks who have made some interesting things happen it won't
work. If we take the intiative and lead them into our world they will
come at it from the perspective that we are professionals who have
created a very credible concept that we are proud of and want them to
enjoy using.
They will ask "What kind of cash have we invested" and if we come back
with "Ahh, well we don't actually have a scope on the financial side of
our open community." They are just going to look around for a while and
leave.
If we can show them that not only are we mathematics and logics wizards
but that we also have solid business sense then they are going to stick
around and see what we have to offer. A lot of them will probably invest
just to test the waters or to keep up with the play.
I want to see an advertising campaign happen that will educate and
encourage the mass of potential user to take the step. I also want to
make sure that we have covered our asses when they finally walk in
through the doors.
It's a choice between being amatuer enthusiasts or professionals.
If we come across as professionals people won't give a toss about
geekyness.
--
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.comHttp://www.djcj.org - The Linux Audio Users guide
========================================
"Um...symbol_get and symbol_put... They're
kindof like does anyone remember like get_symbol
and put_symbol I think we used to have..."
- Rusty Russell in his talk on the module subsystem
[sorry for the wide distribution]
Is anyone out there trying out this combination?:
kernel 2.4.20-rc1
capabilities patch
low latency patch
preemptible kernel patch
almost current alsa cvs [20021028.170432 usa pacific time]
If I start jackd and then use the freqtweak jack client I get a completely
dead machine in a very short time (from a few seconds to 10 or 20
seconds).
Same alsa driver, but running on 2.4.19 (up to 20-pre4) seems to be fine
and I can play around with freqtweak for as long as I want :-)
No clues are left behind... something in the kernel is deadlocking, I
guess. I tried removing first the preemptible kernel patch with the same
result. Just a moment ago I tried again after removing the low latency
patch and I still get the same result... that pretty much leaves alsa and
the kernel. Got the same result on a laptop intel810 and an ice1712 card.
Interestingly enough just the jack server running is not enough to kill
the machine. Adding a jack client (just tried alsaplayer, same problem as
freqtweak) kills the machine really fast.
Maybe there is a problem with the scheduler when there are several
SCHED_FIFO tasks competing for the processor?
-- Fernando
Didn't we come up with some good ammo in case anyone decided to sue?
--
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.comHttp://www.djcj.org - The Linux Audio Users guide
========================================
Being on stage with the band in front of crowds shouting, "Get off! No!
We want normal music!", I think that was more like acting than anything
I've ever done.
Goldie, 8 Nov, 2002
The Scotsman
http://plugin.org.uk/lrdf/
Applied patches from Richard Bown, making it c++ friendly and fixing some
const-isms.
liblrdf is a library for handling RDF (http://www.w3.org/RDF/)
descriptions of LADSPA (and potentially other format) plugins.
It allows grouping of plugins into trees for user slection and finer
description of plugins and ports than the .so format allows (for example
to indicatate textual equivalents of integer port values). It also
provides named and described defaults and presets, metadata and general
semnatic goodness.
examples/example.rdf contains a slighly out of date description of my
plugins. There are some example programs that show how the API works.
- Steve
Hello, all.
This is perhaps totally OT, but with all of the recent conversations
about amp-modeling, I was wondering if anyone had any pointers to how
to build a physical, analog, amp-modeling stompbox or similar (or would
it just be cheaper to buy a SansAmp?) Any direction to get started in
this arena would be helpful.
thanks,
wb
--
Will Benton
http://www.cs.wisc.edu/~willb
"YOW!! That was one of my BEST NIGHTMARES!!"
Hi all --
I'm making my first forays into OSS DSP programming with an eye to
improving the standard linuxaudiodev module included with Python. (And,
of course, to using that module for my own ends!)
I'm rather confused by the semantics of write() in blocking and
non-blocking mode. Specifically, in the default mode (blocking, no
SNDCTL_DSP_NONBLOCK ioctl() call), it appears that write() will happily
write the entire buffer passed to it, and not return until almost all of
the data has been played. (I assume the last dribble is in a
lower-level [hardware?] buffer, so when write() returns there's still a
little bit of sound to be heard.)
However, in non-blocking mode, write() plays roughly 64k or 128k
(depending on the hardware device used) and returns immediately. This
is more like what I was expecting -- I guess the behaviour in blocking
mode is a bit surprising. Is it supposed to be like this? More
importantly, can I *rely* on write() in blocking mode always consuming
the entire buffer passed to it?
BTW, this is with Linux 2.4.20-rc1; the two audio devices are a
SoundBlaster Live using the OSS emu10k1 driver, and a Stereo-Link
external USB audio device using, you guessed it, the USB audio driver.
Thanks --
Greg
--
Greg Ward <gward(a)python.net> http://www.gerg.ca/
I hope something GOOD came in the mail today so I have a REASON to live!!
Hi guys,
I thought I would share some info about some utilities I found recently
with regards to overly painful compile times.
We have done some fairly extensive Corba based stuff at work, the last
few months. Needless to say the compile times we have had for these
beasts are numbing. Standard solution is of course faster machines, but
there are some utils that can help if you got some extra machines at
your disposal.
Have a look at
http://gecc.sourceforge.net/
or
http://distcc.samba.org/
Both these projects (where distcc seem more mature) provide the
possibility to distribute compilations over several machines.
Another solution would be to rewrite everything in Java and use Jikes
:-D...err perhaps not, but it's amazing how fast compilations are using
java and jikes...
Regards,
Robert
- reinventor of the wheel
New Yorkers for Fair Use Action Alert:
--------------------------------------
Please send a comment opposing the "Broadcast Flag" Proposal
to the FCC by this Thursday, December 5, 2002.
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 by the public comments deadline,
this Thursday, December 5, 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 get 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!
Public Comments Needed to Stop the "Broadcast Flag" Proposal
at the FCC
Please follow this link and use the form on the Center for
Democracy and Technology's site to let the FCC know that the
public's rights are at stake:
http://www.nyfairuse.org/action/fcc.flag.xhtml.
What's Going On:
The FCC is considering a proposal that digital televisions
be required to work only according to the rules set by
Hollywood, through the use of a "broadcast flag" assigned to
digital TV broadcasts.
Through the deliberations of a group called the Broadcast
Protection Discussion Group which 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.
Hollywood and content producers must not be allowed to
determine the rights of the public to use flexible
information technology. 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. 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 go to the Center for Democracy and Technology's
Broadcast Flag Action Page and use their form to let the FCC
know that the public's rights are at stake:
http://www.cdt.org/action/copyright/.
----
Some background links:
http://bpdg.blogs.eff.org/archives/one-page.pdfhttp://www.eff.org/effector/HTML/effect15.22.html#IIIhttp://www.cdt.org/press/020807press.shtmlhttp://scriban.com/movabletype_archives/000334.shtmlhttp://scriban.com/movabletype_archives/000331.shtml
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
Woah!
Tack Kjetil!
I've been meaning to construct something like this for a veery long
time, I'm sincerely happy that you managed to pull it of!
Sometime in the near/distant/close/far future I'll be able to test this
(I'm not holding my breath), I can't wait!
So...next step would be VST synths, any chance you would pursue that? :)
Thanks again,
Robert
(now I can concentrate my -100% freetime on my other 101 projects ;-)
Kjetil S. Matheussen wrote:
> VSTServer V0.0.1.
> -----------------
> First release. Beta, but usable.
>
>
> ABOUT
>
> Vstserver is a wine program that must be running when using programs
> using vstlib.
>
> Vstlib is a library that can be used by programs to run windows
> vst audio plugins under linux/freebsd/i386solaris/etc.
>
>
> RUNNING
> Vstserver is started like this: "wine vstserver.so".
> You probably want to set the "VST_PATH" environment variable pointing
> to your plugins first.
>
>
> DEVELOPMENT
> Vstserver is released under the GPL, and vstlib under LGPL.
> If there comes many source-contributions, I will probably make it
> a sourceforge project. To use vstlib in a program, look at
> the tests/exampleclient program, and various vst plug-in documentation.
> The interface to the vstlib consists only of two functions (new/delete),
> the rest is like you would do when programming for windows, macos(X),
> beos, irix, etc.
>
>
> CURRENT STATUS
> Vstserver seems to be very stable. I have not found any plug-ins
> that wont run, and I am not able to hear any latency. And plug-ins
does not
> seem to cause more cpu-power than under windows.
> No GUI or graphics-support yet.
>
>
> BUGS
> 1. When running the ladspa "listplugins" program many times in a row,
> I get the following errors before the server freeze:
>
> err:local:LOCAL_GetBlock not enough space in GDI heap 01f7 for 24 bytes
> err:region:CombineRgn Invalid rgn=0000
> err:local:LOCAL_GetBlock not enough space in GDI heap 01f7 for 24 bytes
> err:region:CombineRgn Invalid rgn=0000
> err:local:LOCAL_GetBlock not enough space in GDI heap 01f7 for 24 bytes
> err:region:CombineRgn Invalid rgn=0000
> err:local:LOCAL_GetBlock not enough space in GDI heap 01f7 for 24 bytes
> err:local:LOCAL_GetBlock not enough space in GDI heap 01f7 for 24 bytes
> err:local:LOCAL_GetBlock not enough space in GDI heap 01f7 for 24 bytes
> err:local:LOCAL_GetBlock not enough space in GDI heap 01f7 for 24 bytes
> err:local:LOCAL_GetBlock not enough space in GDI heap 01f7 for 24 bytes
> err:clipping:CLIPPING_UpdateGCRegion hVisRgn is zero. Please report
this.
>
> I dont know what this is. Its not errors coming from the vstserver
program.
> It seems to be related to X, allthough no graphics is used in the
vstserver.
> I hope its just the buggy libXrender.so library that wine shouts
about each
> time it starts.
>
> 2. Shared memory handlig might be faulty. I suspect that it doesnt free
> resources. (see server/shmhandler.c)
>
> 3. I havent read the vst plug-in documentation yet, and dont know
everything
> about it. This especially goes for the "AudioMasterCallback"
function, which
> for now just returns 1. I guess some more work needs to be done in
this area,
> and for the various dispatch opcodes too.
>
> 4. The processReplacing function in vstlib should perhaps be made
just by calling the
> process fuction. But I dont understand the difference between
processReplacing
> and processing.
>
>
> FUTURE
> Add GUI and graphics support to the server (help wanted). And maybe
make a
> DX-plugin server. (would be fun running pi-warp under linux).
>
>
> CREDITS
> vstserver and vstlib are made by Kjetil S. Matheussen / Notam.
> k.s.matheussen(a)notam02.no
>
> Some programming hints is gathered by looking at the pd vst-object
plugin~ source
> and the jack soundserver source.
>
>
>
>
> vst ladspa plugin v0.0.1 - alpha
> ---------------------------------
>
> Makes vst plugins located in $VST_PATH
> appear as ladspa plugins.
>
> I'm not sure how well this one actually works.
> The northpole plugin seems to work, but others
> don't. Oh well, its alpha for now.
>
>
>
>
> k_vst~, a Pd tilde object for hosting VST plug-ins.
> ---------------------------------------------------
>
> This is really just the plugin~ source made by Jarno Seppänen,
> but with a few lines changed (very few that is) to make it
> work with vst-plugins using the vstlib.
>
> The name was changed from plugin~ to k_vst~ to avoid nameclash
> with the plugin~ object running ladspa plugins.
>
> This object is for i386 non-windows (ie. linux/freebsd) only.
>
> This one works very well!
>
>
>
>
> -------------------------
>
> vstserver, ladspavst and k_vst~ are open-source programs made at Notam /
> Oslo, and can be downloaded from from http://www.notam02.no/arkiv/src/
>
>
>> I heard of USB speakers, could this be a valid solution ?
>> Are they supported under linux ? If yes which kind of models ?
> they're basically usb audio devices with amp and speaker in one
> box - so pretty much all of them work out of box (even the harman
> kardon ones that don't work with windows)
Thanks for the infos, but has anyone tried to work with more than
one signle stereo speakers set at time ?
I fear that bandwidth problems could arise when using 8 channels.
(AFAIK USB1 is 12Mbit)
Anyway these devices seem to be interesting:
http://www.adstech.com/products/USBTurboQuad4/intro/USBTurboQ4.asp?pid=USBX…
" The USB Turbo Quad 4 offers a powerful performance advantage over all
other USB host controllers by providing full USB bandwidth for each port
rather than sharing USB bandwidth over all ports. This results in an
increase in the number of devices that can simultaneously operate. Only
the USB Turbo Quad 4 ensures High-Bandwidth simultaneous operation of
USB devices such as cameras, speakers, scanners, modems and other
bandwidth intensive peripherals."
Just wondering if such a 4 USB port card plus + USB speakers works on
2.4 kernels / ALSA.
cheers,
Benno
--
http://linuxsampler.sourceforge.net
Building a professional grade software sampler for Linux.
Please help us designing and developing it.