>I looked up some prices for online merchant facilities for the
>company I work for and they are not cheap, you have to pay
>a monthly fee and some percentage or forfait per transaction.
Yes but this percentage would be offset/already paid for by a company
that is already running merchant facilities.
>You need a relatively high volume merchant site to go with.
>(economics of scale).
Yes and we definitely have enough people using the software to make
small contributions scale correctly.
>Is Paypal that bad ?
IMO it is another level of red tape that could be bypassed.
>I contributed to Ardour through Paypal and in so far I know,
>it works.
It works but it is not the most effective way of doing things. Users are
required to provide a certain amount of information in order to become a
payee. The recipient is required to pay a surcharge on every transaction
which is higher than the costs imposed by a merchant facility.
Both of those work against us when it comes to making it easy for people
to contribute funds.
I'm interested in the methods that the AGNULA team are using. Maybe they
have already found a solution.
--
Patrick Shirkey - Boost Hardware Ltd.
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
Hi all,
I saw a couple posts on this matter on other lists namely from people
who are trying to make multimedia Linux boxes using CCRMA packages and
RH 8.0.
The issue at hand is that many of the newer machines with cheapo
embedded video cards use Intel 845G chipset which is unsupported by RH
8.0's XFree 4.2. However, XFree 4.3 does support it and so the following
needs to be done (assumption is that you have a reasonably fast internet
connection, otherwise this might prove to be pain -- total d/l amount is
approx. 70MB):
1) Install RH 8.0 in command-line mode (graphics mode will most likely
fail -- it did on mine, although it might have been partially due to use
of an outdated flatscreen monitor that did not allow even the
framebuffer mode)
2) Skip XFree config (if you really feel compelled to configure it, do
NOT test it, it WILL fail)
3) Upon reboot, using Internet connection, connect to the following ftp
in order to retrieve XFree 4.3 version of the x server for the RH 8.0
(you might try the Rawhide mirrors as well but I am not sure whether
those will work):
ftp://people.redhat.com/mharris/testing/unstable/XFree86
(thanks to Mike Harris from Redhat for making them)
4) Install XFree packages by doing:
rpm -Uvh *.rpm --nodeps --force (don't worry it should be ok, at least
it was on mine :-)
5) configure up2date
6) run:
up2date glibc
(you need 2.3.2 for Xfree 4.3, and the one that comes with RH is
2.2.something)
7) Upon finishing installation, run:
redhat-config-xfree86 -o /etc/X11/XF86Config
(you might need to tinker with the config file, depending on your
monitor and other hw)
8) Try starting x server with:
startx
9) Now, you should be up and running, but you still need to enable
acceleration (since otherwise anything with OpenGL will be simply
impossible to use). You need to get the new version of DRI (which
reports errors since the kernel module i830.o is ver.1.2 not 1.3 as
required by Xfree4.3). So go download new DRI package for 4.3 from here:
http://www.xfree86.org/~alanh/linux-drm-4.3.0-kernelsource.tar.gz
(big thanks to Leif Delgass for pointing this out)
10) untar the package and make the new module by doing:
make -f Makefile.linux
11) install the i830.o file by copying it to the
/lib/modules/<kernel-version>/kernel/drivers/char/drm/
(you might wanna backup the old module to something like old-i830.o just
in case something screws up)
12) Now reboot the machine and check the /var/log/XFree86.0.log for any
DRI errors. You might also wanna run the glxgears or something similar
to see if everything is ok. Don't expect much of a fps increase, though
(I had 336 fps on the studio's 2.4GHz P4 machine, while with DRI it went
up to only 400+ fps). What you will, however, see is the smoother moving
the OpenGL window around the desktop and generally better system
responsiveness.
Now I can even play the Tuxracer at a reasonable framerate. Yay! That's
it. Hope someone finds this helpful. Cheers!
Ivica Ico Bukvic
http://meowing.ccm.uc.edu/~ico
hello everyone !
for those who are interested, some tapes from the presentations at the
LAD meeting are now online at
http://www.linuxdj.com/audio/lad/eventszkm2003.php3 ,
together with the slides and the long-awaited mug shots by fernando :)
i'll be off for a week now, and unfortunately i won't get all of the
stuff uploaded in time... check back in a week or so.
best,
jörn
ps: some links are currently broken. will be fixed asap.
--
All Members shall refrain in their international relations from
the threat or use of force against the territorial integrity or
political independence of any state, or in any other manner
inconsistent with the Purposes of the United Nations.
-- Charter of the United Nations, Article 2.4
Jörn Nettingsmeier
Kurfürstenstr 49, 45138 Essen, Germany
http://spunk.dnsalias.org (my server)
http://www.linuxdj.com/audio/lad/ (Linux Audio Developers)
hi... this is my first time online since lad Conference.
so i would like to announce galan-0.2.14 (as seen on lad Conference)
galan is another modular synthesizer. It supports sub patches like pd
and jmax. But has separation of mesh and Controls.
It also supports OpenGL Scene Graphs which can be controlled by your
audio data, the sequencers etc...
homepage is at
http://galan.sourceforge.net
find the download links from there...
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
This is a brief rundown of the results from the advertising campaign I
launched last October.
I have paused it for now but will resume it again in 6 months time for
the Xmas season.
I placed four adgroups, with a total of 2390 clicks, 222573 page
impressions, costing $450.24 over 6 months.
Full Summary below:
Report for Oct 20, 2002 to Mar 26, 2003
Campaign Summary
All Campaigns Clicks Impr. CTR Avg. CPC (USD) Cost (USD) Avg. Pos
Campaign #1 991 106549 0.9% $0.26 $255.95 2.9
Campaign #2 462 80096 0.5% $0.12 $54.18 1.3
Campaign #3 930 33583 2.7% $0.15 $139.33 1.2
Campaign #4 7 2345 0.2% $0.11 $0.78 1.5
Overall 2390 222573 1.0% $0.19 $450.24 2.1
*Reporting is not real-time. Clicks and impressions received in the last
12 hours may not be included here.
Campaign #1 - USD $1.50 daily budget limit View/Edit
Ad Groups Clicks Impr. CTR Avg. CPC (USD) Max. CPC (USD) Cost (USD) Avg. Pos
music recording - Paused 991 106549 0.9% $0.26 $0.50 $255.95 2.9
Overall 991 106549 0.9% $0.26 - $255.95 2.9
Campaign #2 - USD $1.00 daily budget limit View/Edit
Ad Groups Clicks Impr. CTR Avg. CPC (USD) Max. CPC (USD) Cost (USD) Avg. Pos
linux sound - Paused 462 80096 0.5% $0.12 $0.50 $54.18 1.3
Overall 462 80096 0.5% $0.12 - $54.18 1.3
Campaign #3 - USD $1.00 daily budget limit View/Edit
Ad Groups Clicks Impr. CTR Avg. CPC (USD) Max. CPC (USD) Cost (USD) Avg. Pos
Linux music - Paused 930 33583 2.7% $0.15 $0.50 $139.33 1.2
Overall 930 33583 2.7% $0.15 - $139.33 1.2
Campaign #4 - USD $1.00 daily budget limit View/Edit
Ad Groups Clicks Impr. CTR Avg. CPC (USD) Max. CPC (USD) Cost (USD) Avg. Pos
sound - Paused 7 2345 0.2% $0.11 $0.50 $0.78 1.5
Overall 7 2345 0.2% $0.11 - $0.78 1.5
--
Patrick Shirkey - Boost Hardware Ltd.
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
I fear we've all been very busy. I know I have. I have not had time to
devote to XAP, though I have certainly not lost interest.
So today I start looking at my evolving spec doc again. The biggest chunk
of undecidedness lies in the area of Channels. We never really resolved the
Bays/Channels etc debate. We just put it off. Here it is.
I'd like to propose the following - it is simple and flexible. Not too
confusing.
Plugins define 'Modules'. Every plugin has a master Module, and 0-n extra
Modules. The host can instantiate Modules as needed. A Module is analogous
to a MIDI Channel in a synth (maybe Module is the wrong word). It is
analogous to a slot in a mixer.
struct XAP_descriptor {
...
/* master module descriptor */
XAP_module master;
/* other channel descriptors */
int n_modules;
XAP_module *modules;
/*
* Instantiate a module, return a plugin-unique
* id/index for it - it's 'Channel'.
*/
int (*add_module)(void *plugin, int module);
/*
* Remove a module.
*/
int (*del_module)(void *plugin, int index);
};
struct XAP_module {
char *label;
char *name;
uint32_t flags;
/* how many instances of this module are allowed? */
int count_max;
/* per-module controls and I/O */
int n_controls;
XAP_control **controls;
int n_ports;
XAP_port **ports;
};
Hi everyone,
There are 2 MIDI System Common opcodes (0xF4 and 0xF5) and 2 MIDI
System Realtime opcodes (0xF9 and 0xFD) that the official MIDI
standard reserves for future use.
I'm currently collecting examples of non-standard uses of these
opcodes in hardware and software (on MIDI 1.0 DIN cables and in other
hardware and software contexts). Examples I've collected so far are:
-- 0xF9 as "MIDI Tick"
-- 0xF5 for both "MIDI endpoint" and "virtual cable" selection
I'm doing this as part of the process of finishing:
http://www.cs.berkeley.edu/~lazzaro/sa/pubs/txt/current-mwpp.txthttp://www.cs.berkeley.edu/~lazzaro/sa/pubs/txt/current-guide.txt
It uses the semantics of the commands as part of its resiliency
scheme, and so knowledge of non-standard uses of the reserved commands
is needed to help craft resiliency logic for the opcodes. Probably
best to send the info directly to lazzaro(a)cs.berkeley.edu, the topic
is too mundane for the list ... thanks in advance!
-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------
Hi all,
I would like to announce creox 0.2.0
- the realtime sound processor for KDE
http://www.uid0.sk/zyzstar/?creox
As Creox is a JACK application, the output sound can be routed to the
other JACK-aware applications, and the audio input can be taken as the
output from the other JACK client.
--
jozef kosoru
Hi LADs,
here is a problem that maybe very common with many rt audio apps, so
hopefully there is a "standard" solution for it?
assume jack process callback reads audio data from a buffer, while
another thread might alter the
contents of this buffer. In my particular scenario, i will actualy use
doublebuffering. So the only operation that needs to be "mutexed"
is the actual swapping of front and back buffers (well, pointers, of
course, not the contents)
Now my problem is: How can i make sure that swapping does not accure
during process (playback) callback?
I could use a mutex, but this might also block the playback thread. (if
swapping is in process when the jack callback is invoked)
On the other hand, swapping pointers shouldn't take that long, so maybe
this would not be a problem?
Or would it make sense to try and "foresee" such a situation and avoid
it by delaying the swapping?
Any clever suggestions on this?
Regards,
Lukas
http://www.fftw.org/
Just a headsup for all the people who link against it. Hopefully they've
normailised the build system now...
Looks pretty good, now includes SIMD optimisations.
- Steve