| Hi,
I think it may already have been asked before but could someone with
an extended csound board please indicate the performance via
use of the standard benchmarks? I know the benchmarks are now
supposed to be too slow to be of interest but it would be
interesting to see how the card fares.
I mentioned in a previous post my desire to see some alternative to
midi come into existence. I absolutely agree with Larry Troxler when he
says =
> look up ZIPI, and also what Perry Cook has to offer...
There are already many excellent event formats available just little
software supports it. Syncing to our sequencers would be essential.
All that i was suggesting was some form of gui for sequencing / editing
an extended message format. Most musical data should be interchangeable
anyway it is just that in some directions ie. csound to midi - data will
be lost via quantization. The format of the message should be agreed
and then we need to get drivers written for all our diverse os's.
A non trivial task i think but possible. The actual interfaces that
could
be of interest to support are :
1. Internal bus. To a sound / synthesizer card.
Should be provided by manufacturer.
2. USB - mainly intel based so a bit crap.
3. Firewire - good mac and pc support but i feel workstations are no
go.
Amazingly fast interface with support for control and event
streams.
4. TCPIP Sockets - universally supported ?but has latency issues?
5. Any others anyone knows about?
On a seperate tack - Michael Gogins wrote...
> This is because it takes much less time to write software than it does to
> create chips and firmware, and regular PCs are now fast enough to do
> considerable DSP and synthesis in real time.
> In the first place, I firmly believe that the future of music lies strictly
> in software, the only hardware being the computer itself, the control
Well software has to be running on both processors whether host or dsp.
Hopefully Ansi C should make the development task similar. The chip
company
should design the chip and either them or the sort of company that makes
sound blaster clones for $25 should put them on a board and write a
message driver.
Software synthesis code handles the low level oscilators, effects and io
and then all subsequent development happens in the orc language
so subsequent development costs should be identical. External boxes have
the advantage of being platform independent and very scalable but plug
in
cards can be much cheaper.
It surely should be in ADIs (or other chip firms) interest to create the
firmware, software, hardware and also drivers because then they will
sell shedloads more chips. A market will not form in my opinion unless
the development environment is up to it. If they do not want to create
then they could fund / licence possibly.
...
> and regular PCs are now fast enough to do
> considerable DSP and synthesis in real time.
I disagree with the above statement with respect to complexity and
with latency. Although pcs make excellent guis it is too much to
expect <1ms latency on multiple audio streams and i feel this may be
the case for a number of years. This means that chaining of devices
becomes impossible.
A recent post talked about parallel processing not giving 100%
efficiency gain per added processor. While this is true for shared
memory it is not necessarily the case for external chips as long
as the interconnect is up to it - midi is not unfortunately.
I think the problem with tcp/ip is that it also has latency troubles,
although i don't have any figures.
Just some thoughts,
Mike Chapman. |