10 Feb
2003
10 Feb
'03
11:49 p.m.
The Generalized Music Plug-In Interface (GMPI) working group of the MIDI
Manufacturer's Association (MMA) is seeking the input of music and audio
software developers, to help define the technical requirements of GMPI.
The objective of the GMPI working group is to create a unified
cross-platform music plug-in interface. This new interface is hoped to
provide an alternative choice to the multitude of plug-in interfaces that
exist today. Among the many benefits of standardization are increased
choice for customers, lower cost for music plug-in vendors and a secure
future for valuable market-enabling technology.
Like MIDI, GMPI will be license free and royalty free.
Phase 1 of the GMPI working group's effort is to determine what is required
of GMPI: What sorts of capabilities are needed to support existing products
and customers? What are the emerging new directions that must be addressed?
Phase 1 is open to any music software developer and is not limited to MMA
members. It will last a minimum of three months, to be extended if deemed
necessary by the MMA. Discussions will be held on an email reflector, with
possible meetings at major industry gatherings such as AES, NAMM and Musik
Messe.
Following the collection of requirements in Phase 1, the members of the MMA
will meet to discuss and evaluate proposals, in accordance with existing MMA
procedures for developing standards. There will be one or more periods for
public comment prior to adoption by MMA members.
If you are a developer with a serious interest in the design of this
specification, and are not currently a member of the MMA, we urge you to
consider joining. Fees are not prohibitively high even for a small
commercial developer. Your fees will pay for administration, legal fees and
marketing. Please visit http://www.midi.org for more information about
membership.
To participate, please email gmpi-request(a)freelists.org with the word
"subscribe" in the subject line. Please also provide your name, company
name (if any) and a brief description of your personal or corporate domain
of interest. We look forward to hearing from you.
Sincerely,
Ron Kuper
GMPI Working Group Chair
11 Feb
11 Feb
6:45 a.m.
On Mon, Feb 10, 2003 at 10:42:48 -0500, RonKuper(a)Cakewalk.com wrote:
Like MIDI, GMPI will be license free and royalty
free.
Phase 1 of the GMPI working group's effort is to determine what is required
of GMPI: What sorts of capabilities are needed to support existing products
and customers? What are the emerging new directions that must be addressed?
Thanks for starting this Ron, I for one hope that it will be successful.
I'd guess that us Free Software types are going to want a more strict
definition of "licence free" ;), so can I suggest we argue amongst
ourselves about what we'd like in the way of licencing before spamming the
list.
Some sort of (seperate, technical) statement from the l-a-d community
about what features we'd like is probably a good idea too. We have more
experiences in some areas than the closed plugin systems, eg. plugins as
modular synth modules, natural ranges*, seperating UIs from DSP code** and
metadata.
* unless MAS or TDM do this, I dont know anything about them.
** except TDM and hardware accelerated VST, and modulo obove
- Steve
7:23 a.m.
On Tuesday 11 February 2003 11.37, Steve Harris wrote:
[...]
I'd guess that us Free Software types are going to
want a more
strict definition of "licence free" ;), so can I suggest we argue
amongst ourselves about what we'd like in the way of licencing
before spamming the list.
Well, one thing I consider *very* important is the management of
Unique IDs. MIDI SysEx and DLS IDs are *not* free in any way, so the
only reason MIDI can be considered Free is that you can do a lot of
stuff with MIDI without having your own IDs. Inded, a Free/Open
Source MIDI application *could* have it's own IDs if someone cares to
pay for them annually - but what happens when payments stop...?
With plugins, IDs are no longer optional, so claiming that the
standard is Free would obviously be ridiculous if a similar
registration system was used.
Anyway, I'd propose that IDs are separated into two parts;
Manufacturer ID (globally registered) and Product ID (managed by
manufacturers individually).
If this makes someone nervous about too many Free implementations
eating the ID space or something, make each field 32 bits, and/or
reserve part of the range for paying manufacturers, or whatever.
[...]
** except TDM and hardware accelerated VST, and modulo
obove
Hardware accelerated VST plugins just serve as interfaces to their DSP
hardware, like a driver, basically. They still run in the audio
thread of the host, using process() (as usual) to deliver data, and
an additional polling call for the host to find out when the output
is ready. That is, it's not a separation, but rather a low level
feature for the DSP part of plugins.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
10:51 a.m.
On Tue, Feb 11, 2003 at 12:16:22 +0100, David Olofson wrote:
On Tuesday 11 February 2003 11.37, Steve Harris
wrote:
[...]
I've probably suggested this before, but the URI scheme works, anyone who
has control over a domain/website can issue URIs, eg. I could use
http://plugin.org.uk/gmpi#myPluginName
or something of that form. Its robust (relies on the DNS system),
and centrally, externally and impartially administered.
It could be a requirement that the URI resolves to some information about
the plugin. Or not.
If the $30 a year domain registration fees are too onerous, use a free
website provider like geocities or such.
- Steve
I'd guess that us Free Software types are
going to want a more
strict definition of "licence free" ;), so can I suggest we argue
amongst ourselves about what we'd like in the way of licencing
before spamming the list.
Well, one thing I consider *very* important is the management of
Unique IDs. MIDI SysEx and DLS IDs are *not* free in any way, so the
only reason MIDI can be considered Free is that you can do a lot of
stuff with MIDI without having your own IDs. Inded, a Free/Open
Source MIDI application *could* have it's own IDs if someone cares to
pay for them annually - but what happens when payments stop...?
4:07 p.m.
On Tuesday 11 February 2003 15.43, Steve Harris wrote:
[...]
I've probably suggested this before, but the URI
scheme works,
anyone who has control over a domain/website can issue URIs, eg. I
could use
http://plugin.org.uk/gmpi#myPluginName
or something of that form. Its robust (relies on the DNS system),
and centrally, externally and impartially administered.
Works for me, although I'm not totally happy about the fact that
domains do expire whenever the owner decides they don't care any
longer. And if users have plugins created by someone who owned
www.xap-plugins.com, and someone else takes over the domain name...
Well, you get the idea!
We could allow the use of CPU IDs, NIC MAC addresses and that sort of
stuff. Just specify cpuid://, mac:// or whatever before it, to avoid
conflicts between the spaces.
Of course, an audio hacker *might* sell or give a NIC, a CPU or
whatever to some other audio hacker... So it might be a good idea to
include the developer's name or something, just in case! ;-)
It could be a requirement that the URI resolves to
some information
about the plugin. Or not.
In fact, considering the above, we might even want to *discourage*
that. Use another field for URLs, because it's a different thing.
Also, what do you do with your URIs if you move the home site?
If the $30 a year domain registration fees are too
onerous, use a
free website provider like geocities or such.
Or find the some owner of a domain likely to hang around for a good
while and ask if you can use a "virtual" sub-directory under that
domain for your plugins. (Ex: "http://olofson.net/steves-plugins#*".
No guarantee that I'll live longer than your plugins, though! ;-)
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
8:29 p.m.
On Tue, Feb 11, 2003 at 08:59:32PM +0100, David Olofson wrote:
Yes, you have to prevent that sort of thing.
Yes, these are the downsides to recommending URIs be resolvable.
Its generally not a good idea, but occasionally it makes sense.
Sure, nothings perfect :(
If your really worried about longevity you can still request a sub-URI
from an authority (like LADSPA uids are handed out), eg.
http://www.xap.org/steves-plugins/...
- Steve
I've
probably suggested this before, but the URI scheme works,
anyone who has control over a domain/website can issue URIs, eg. I
could use
http://plugin.org.uk/gmpi#myPluginName
or something of that form. Its robust (relies on the DNS system),
and centrally, externally and impartially administered.
Works for me, although I'm not totally happy about the fact that
domains do expire whenever the owner decides they don't care any
longer. And if users have plugins created by someone who owned
www.xap-plugins.com, and someone else takes over the domain name...
Well, you get the idea! It could be a
requirement that the URI resolves to some information
about the plugin. Or not.
In fact, considering the above, we might even want to *discourage*
that. Use another field for URLs, because it's a different thing.
Also, what do you do with your URIs if you move the home site? If the $30 a
year domain registration fees are too onerous, use a
free website provider like geocities or such.
Or find the some owner of a domain likely to hang around for a good
while and ask if you can use a "virtual" sub-directory under that
domain for your plugins. (Ex: "http://olofson.net/steves-plugins#*".
No guarantee that I'll live longer than your plugins, though! ;-)
9:22 p.m.
New subject: [linux-audio-dev] XAP domain [was: Call for participation: MMA GMPI working group]
On Wednesday 12 February 2003 01.21, Steve Harris wrote:
[...]
If your really worried about longevity you can still
request a
sub-URI from an authority (like LADSPA uids are handed out), eg.
http://www.xap.org/steves-plugins/...
BTW, should I grab that domain? (Before someone else does, just to
piss us of or something.) Could point it directly at my XAP site for
now.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
9:36 p.m.
New subject: [linux-audio-dev] XAP domain [was: Call for participation: MMA GMPI working group]
If your really
worried about longevity you can still request a
sub-URI from an authority (like LADSPA uids are handed out), eg.
http://www.xap.org/steves-plugins/...
BTW, should I grab that domain? (Before someone else does, just to
piss us of or something.) Could point it directly at my XAP site for
now.
9:54 p.m.
New subject: [linux-audio-dev] XAP domain [was: Call for participation: MMA GMPI working group]
On Wednesday 12 February 2003 02.23, Tim Hockin wrote:
if it is available, go for it. Or I can stick it on my co-lo if
you prefer.
.com, .net, .info and .biz are taken, but only .com is in use. org,
nu, se, no, dk, cc, to, st and cx are available.
Question is what Xap Corporation thinks about our choice of name...
Either way, I'm just a few clicks away from [www.]xap.org for 2 years
with automatic extension. Go? :-)
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
If your really worried about longevity you can still
request a
sub-URI from an authority (like LADSPA uids are handed out),
eg. http://www.xap.org/steves-plugins/...
BTW, should I grab that domain? (Before someone else does, just
to piss us of or something.) Could point it directly at my XAP
site for now.
10:01 p.m.
New subject: [linux-audio-dev] XAP domain [was: Call for participation: MMA GMPI working group]
Either way, I'm just a few clicks away from
[www.]xap.org for 2 years
with automatic extension. Go? :-)
go for it - we'll pitch in and help cover the (20 dollars?) cost :)
10:16 p.m.
New subject: [linux-audio-dev] XAP domain [was: Call for participation: MMA GMPI working group]
On Wednesday 12 February 2003 02.48, Tim Hockin wrote:
That won't ruin me, so there's no need for that. :-)
Unfortunately, my bank server is closed this time of day, so I can't
get any further right now. The ISP is waiting for the payment.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
Either way,
I'm just a few clicks away from [www.]xap.org for 2
years with automatic extension. Go? :-)
go for it - we'll pitch in and help cover the (20 dollars?) cost :)
10:42 p.m.
New subject: [linux-audio-dev] XAP domain [was: Call for participation: MMA GMPI working group]
go for it -
we'll pitch in and help cover the (20 dollars?) cost :)
That won't ruin me, so there's no need for that. :-)
Unfortunately, my bank server is closed this time of day, so I can't
get any further right now. The ISP is waiting for the payment.
11 p.m.
New subject: [linux-audio-dev] XAP domain [was: Call for participation: MMA GMPI working group]
On Wednesday 12 February 2003 03.28, Tim Hockin wrote:
would you rather I get it? I can still get it today
Well, I rather like the speedy services of the ISP (*), the order is
placed, and the bank opens in about two hours...
(*) Like adding features to the web mail interface in less
than two hours after I suggest them - and that long only
because I was too early for the Nightly Hacker. ;-)
Anyway, perhaps we should put a link to GMPI on the site?
If nothing else, it would make it clear that we're actually in on it,
rather than unaware of it's existence, working against it or
whatever.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
go for it - we'll pitch in and help cover the (20
dollars?)
cost :)
That won't ruin me, so there's no need for that. :-)
Unfortunately, my bank server is closed this time of day, so I
can't get any further right now. The ISP is waiting for the
payment.
4:02 p.m.
Some sort of (seperate, technical) statement from the
l-a-d community
about what features we'd like is probably a good idea too. We have more
experiences in some areas than the closed plugin systems, eg. plugins as
modular synth modules, natural ranges*, seperating UIs from DSP code** and
metadata.
Yes - rather than flood with duplicate requests.
My immediate thoughts:
* Implementable in C, not C++
* Agnostic about multiple inputs/outputs
* Event driven
* No MIDI legacy, but able to automagically connect MIDI hints
* Named audio ports (Left, Right, etc) for clever connections between plugins
* Native support/hints for control types
- Float/Int
- Boolean
- Enum
- String
* Arbitrary per-voice continuous controls
* Some way to seek into long samples (optional for plugins to support)
* Mono float buffers
4 Oct
4 Oct
2:11 p.m.
New subject: [linux-audio-dev] GAP: Audio API again
Sorry to bother you all again: just some thoughts...
- I don't wont to be too negative with respect to the GMPI effort,
because it's a great chance for free software developers to take part in
the discussion of the spec of what could be become an important
standard.
- BTW, after the "Phase 1" of GMPI developing process, developers who
are not member of MMA will have to sit and wait. Hoping:
a) that the final standard will be similar to what she/he wanted (i.e.
what was decided on the mailing list);
b) that the license and the way the standard is designed will be really
"free".
On Tue, 2003-02-11 at 04:42, RonKuper(a)Cakewalk.com wrote:
Phase 1 of the GMPI working group's effort is to
determine what is required
of GMPI: What sorts of capabilities are needed to support existing products
and customers? What are the emerging new directions that must be addressed?
[...]
Following the collection of requirements in Phase 1,
the members of the MMA
will meet to discuss and evaluate proposals, in accordance with existing MMA
procedures for developing standards. There will be one or more periods for
public comment prior to adoption by MMA members.
If you are a developer with a serious interest in the design of this
specification, and are not currently a member of the MMA, we urge you to
consider joining. Fees are not prohibitively high even for a small
commercial developer. Your fees will pay for administration, legal fees and
marketing. Please visit http://www.midi.org for more information about
membership.
I know that "free" is a vague word, and we may not all need
the same
kind of freedom (speaking about software). Probably the best way to
proceed to design an API with contribution by many people on a mailing
list is to define the license (and target plugin developers and users)
as *the first step* (though may take some extra initial time).
I want an API that may be extensible; but doing audio programming just
in my limited free time (here "free" is clear:) as a hobby, I want those
extensions to be contributed back to the community (in the LGPL sense);
I want to develop open source plugins and would like others to do the
same, but I want to allow skilled company to write wonderful plugins and
to earn money for that (again in the LGPL sense).
I certainly don't want to pay *any* money (at least to be payed:-) to be
involved in a project that will make earn money to other people or
association (unless it is Amnesty International or that kind).
I want to be involved in the design process, not just to wait for it to
be completed by MMA members.
What I want is an API with the spirit of free software (in the GNU
sense). If XAP will abandoned, maybe I should simply create my API, host
and plugins. I would like to call it GAP (GNU Audio Plugin)
(though I still have to look for name conflicts with other projects).
Perhaps someone else will use it and will want to contribute it.
Maybe I have only 2 alternative:
a) Hope that MMA will reconsider the design phase.
b) Develop my own API (hopefully with other free software developers).
c) Don't care, and do other things in my free time.
- I'm having difficulties to follow the item on the agenda as some of my
ideas for an ideal (i.e. to be used in many years to come) API are not
completely in accordance with some concept of the agenda.
Ciao,
Marco
3:15 p.m.
New subject: [linux-audio-dev] GAP: Audio API again
- I don't wont to be too negative with respect to
the GMPI effort,
because it's a great chance for free software developers to take part in
the discussion of the spec of what could be become an important
standard.
its not just a great chance. its the ONLY chance.
- BTW, after the "Phase 1" of GMPI developing
process, developers who
are not member of MMA will have to sit and wait. Hoping:
there is nothing stopping "LAD" from joining the MMA. it is very
likely that Linux Audio Systems will join the MMA, and i will be happy
to act as a proxy for LAD if necessary.
a) that the final standard will be similar to what
she/he wanted (i.e.
what was decided on the mailing list);
b) that the license and the way the standard is designed will be really
"free".
the license is part of the agenda. we haven't reached it yet, but i
think it was clear from the very beginning (a meeting at NAMM) that
the outcome would be very close to the LGPL. everybody admires the
openness of MIDI and the lack of proprietary control, while also being
aware of the risks of stuff like GM and XM that were added to MIDI by
Roland and Yamaha.
I want an API that may be extensible ...
I want those extensions to be contributed ...
I want to develop open source plugins ...
I want to allow skilled company to write wonderful plugins ...
I certainly don't want to pay *any* money (at least to be payed:-) ...
I want to be involved in the design process, ...
What I want is an API with the spirit of free software ...
you seem to want a lot.
look, most of the people on the GMPI list would love to be able to
define the plugin API they use to meet all their own needs and
desires. unfortunately, we've already seen the result of this approach
- multiple API's most of which have identical core functionality and
make life miserable for developers and users. this is the prime reason
why the GMPI effort exists at all, but unless the API that will
hopefully emerge from it is actually accepted and used by major host
applications, it will be pointless. what is the chance that your (or
my) pet API will succeed in that sense?
sense). If XAP will abandoned, maybe I should simply
create my API, host
and plugins. I would like to call it GAP (GNU Audio Plugin)
Great. Another API. Besides, the GNU project already has Octal, which
probably overlaps with this very significantly.
a) Hope that MMA will reconsider the design phase.
b) Develop my own API (hopefully with other free software developers).
c) Don't care, and do other things in my free time.
i hope its (c). (a) is important because we've already seen how slow
the requirements process is when its open to anyone on a mailing
list. (b) is just going to make things more confusing for
everyone. please wait for GMPI to fail first.
- I'm having difficulties to follow the item on the
agenda as some of my
ideas for an ideal (i.e. to be used in many years to come) API are not
completely in accordance with some concept of the agenda.
i'm afraid you're late to the party. i seem to recall you saying you
were relatively new to this. i would pay close attention to what the
core tech guys from Cakewalk, FXpansion, Adobe, DestroyFX, Prism,
Steve Harris Inc., and several other organizations have to say. Tim
Hockin has done a wonderful job, aided by David Olofson, representing
a more expansive vision of what GMPI might be. the agenda wasn't put
together by a bunch of suits - it was the result of discussions by a
few dozen of the most experienced audio programmers around. if you
have something to contribute, join the GMPI list rather than talking
about it on LAD.
--p
4:24 p.m.
New subject: [linux-audio-dev] GAP: Audio API again
On Sat, Oct 04, 2003 at 01:03:26PM -0400, Paul Davis wrote:
Agreed here. If you want to do B, you should do it knowing that it will run
in your app, and if you are VERY LUCKY, a few other linux apps. Don't think
you can change the industry by yourself. I'd have kept up on XAP if I
thought GMPI was useless.
a) Hope that
MMA will reconsider the design phase.
b) Develop my own API (hopefully with other free software developers).
c) Don't care, and do other things in my free time.
i hope its (c). (a) is important because we've already seen how slow
the requirements process is when its open to anyone on a mailing
list. (b) is just going to make things more confusing for
everyone. please wait for GMPI to fail first. >- I'm having difficulties to follow the item
on the agenda as some of my
>ideas for an ideal (i.e. to be used in many years to come) API are not
>completely in accordance with some concept of the agenda.
I've offered to answer any questions/concerns you have about already
discussed items. We're still in the requirements phase, so PLEASE - tell us
your requirements (and justify them). I will spend my own personal time
rehashing GMPI discussions to bring you up to speed. If you have a legit
requirement that we have screwed up, I'll bring it up to the GMPI group.
together by a bunch of suits - it was the result of
discussions by a
few dozen of the most experienced audio programmers around. if you
have something to contribute, join the GMPI list rather than talking
about it on LAD.
Also an option. :)
Like I said, if you have issues with existing decisions - ask me about them,
and I'll dredge out the best explanations I can.
Tim
--
Notice that as computers are becoming easier and easier to use,
suddenly there's a big market for "Dummies" books. Cause and effect,
or merely an ironic juxtaposition of unrelated facts?
5:35 p.m.
New subject: [linux-audio-dev] GAP: Audio API again
On Sat, 2003-10-04 at 19:03, Paul Davis wrote:
Yeah, maybe. But they may all seem reasonable requests from
the point of
view of a developer who does it for free.
:(
This is the problem of free software, too many projects with same goals.
But hey, I'm doing it for free and for me, giving eventual results to
anyone who wants. I don't see in this sense why it is so negative.
I agree with you on the reasons for not creating a new API, I am only
not so happy with the fact that actual development will be done only by
MMA members.
I'm not so skilled like the developers you cited, but perhaps I can
contribute with some ideas I didn't see considered. I haven't done it
yet for the reasons I've written.
Marco
the license is part of the agenda.
From my POV, the license and target plugin developers and users should
be the first
item to be agreed with MMA.
I want an API
that may be extensible ...
I want those extensions to be contributed ...
I want to develop open source plugins ...
I want to allow skilled company to write wonderful plugins ...
I certainly don't want to pay *any* money (at least to be payed:-) ...
I want to be involved in the design process, ...
What I want is an API with the spirit of free software ...
you seem to want a lot. look, most of the people on the GMPI list would love
to be able to
define the plugin API they use to meet all their own needs and
desires. unfortunately, we've already seen the result of this approach
- multiple API's most of which have identical core functionality and
make life miserable for developers and users.
If, as for LADSPA we could define a
*good* API that hosts will use,
the MMA could later accept it as a standard de facto.
LADSPA is simple (simpler than this new API) but it worked for it.
You and other developers on LAD developed it without the MMA.
Great. Another API. Besides, the GNU project already
has Octal, which
probably overlaps with this very significantly.
In fact, I was thinking of plugins
for Octal, which eventually could be
THE host (but it of course depends on how Octal will evolve).
a) Hope that
MMA will reconsider the design phase.
b) Develop my own API (hopefully with other free software developers).
c) Don't care, and do other things in my free time.
i hope its (c). (a) is important because we've already seen how slow
the requirements process is when its open to anyone on a mailing
list. (b) is just going to make things more confusing for
everyone. please wait for GMPI to fail first.
7:20 p.m.
New subject: [linux-audio-dev] GAP: Audio API again
I'm not so skilled like the developers you cited,
but perhaps I can
contribute with some ideas I didn't see considered. I haven't done it
yet for the reasons I've written.
I haven't seen any reasons for keeping quiet except that you aren't happy
the MMA is running, it, which is hardly a reason. If you want to have
influence, open your mouth and tell us what you think is wrong.
--
Notice that as computers are becoming easier and easier to use,
suddenly there's a big market for "Dummies" books. Cause and effect,
or merely an ironic juxtaposition of unrelated facts?
7716
days inactive
7952
days old
linux-audio-dev@lists.linuxaudio.org
18 comments
6 participants
participants (6)
-
David Olofson -
Marco Ballini -
Paul Davis -
RonKuper＠Cakewalk.com -
Steve Harris -
Tim Hockin