MUFF WIGGLER Forum Index
 FAQ & Terms Of UseFAQ & Terms Of Use   Wiggler RadioWiggler Radio   SearchSearch   Muff Wiggler Blog & NewsBlog & News   Muff Wiggler StoreMW Store 
 RegisterSign up   Log inLog in 

And yet another euro player.
MUFF WIGGLER Forum Index -> Alyseum Goto page Previous  1, 2 [all]
Author And yet another euro player.

jupiter8

I've been reading a lot about this the last few days and it is really interesting.
I'm a bit miffed by yet another standard but this one seem to be gaining ground really quick. There's already 2 standards for midi over ethernet but i guess you need something new to finally break away from midi. But then there's OSC but that doesn't seem to gain any momentum for the moment.

I haven't really tried it but i believe you can bridge from say rtpmidi to CopperLan quite easily if you want to. To the computer they're just midi ports like any other.

And now answer time:
poladark wrote:
I love the idea...

But... from a purely technical standpoint.... There doesn't seem to be a public document specifying the protocol - yet they claim that the CopperLAN protocol is "open".

You can apply for a freeware yada yada yada and you get access to the format. I did yesterday but haven't really looked into it yet.
poladark wrote:
Not using IP seems like a serious disadvantage. How are you supposed to use this with existing network infrastructure? Can i use my enterprise class Cisco switches and routers with CopperLAN? What if i want to collaborate with a person downstairs or in a different office? The advantage of using Ethernet with CopperLAN is not so obvious if I'd have to design a physically separate network to use it.

If i wanted to invest in CopperLAN audio infrastructure it would need to be a technically sound solution.

You need not worry. It can coexist on an existing network so no problems there.
asterisk wrote:
i wonder if this thing can do more discrete CV steps in copperlan mode than in midi mode?

That is kinda the point behind CopperLan so i'd be really surprised if that is not the case.


poladark

jupiter8 wrote:
You can apply for a freeware yada yada yada and you get access to the format. I did yesterday but haven't really looked into it yet.

Registered for that now as well. Doesn't appear to be any "Non-Disclosure Agreement" to sign, thankfully. If the network protocol is sound, I'd love to give programming this a go. MIDI never was very flexible :(

jupiter8 wrote:
It can coexist on an existing network so no problems there.

Maybe I'm overthinking this. Coexisting on an existing network is great - but routing is done on the IP level. If there is no IP protocol, then the protocol will get as far as a switch, but it won't get past a router. If that is the case however, something like VLAN tagging might work for bigger networks... possibly.


Endosine

poladark wrote:

Maybe I'm overthinking this. Coexisting on an existing network is great - but routing is done on the IP level. If there is no IP protocol, then the protocol will get as far as a switch, but it won't get past a router. If that is the case however, something like VLAN tagging might work for bigger networks... possibly.


Much like TCP or UDP can both run at the same time on a network, so can CopperLAN. They wrote their own protocol to get the great user experience of ZeroConf (automatic device discovery) and extremely low latentcy. If they had built it using TCP/IP the latency would be too high/irregular for realtime data. You probably wouldn't see CopperLAN beyond a router unless the router was aware of the protocol and passed it on. There is a large broadcast aspect to the protocol so I don't think having the router pass it would generally be a good thing. It's not intended to be a "over the internet" thing, just a local area tool. The Jazzmutant Lemur and some other OSC devices often routed over UDP to get away from the overhead of TCP and help things be closer to realtime. The tradeoff there was UDP has no handling of "lost packets" or handshaking, so if you are on a busy network UDP can have troubles.

/past life as an IT guy

As a synth nerd the new module looks really interesting...


no-fi

I like this - I have a spare ethernet port on my PC, but no spare adat lightpipe... keen to hear about how well it works and see the results of timing tests


mateo

It's worth looking at the manual for more info:

http://www.alyseum.com/downloads/ALYSEUM_MS-812%20_Eurorack__User's%20 Manual%20no%20SW_V1.3_EN.pdf


poladark

It's starting to feel like I'm playing the Devil's Advocate here. I really do think it's a cool technology but there are some things that make me doubt the flexibility of this solution.

Endosine wrote:
If they had built it using TCP/IP the latency would be too high/irregular for realtime data.
This is simply not true in the context of CopperLAN. In the financial trading sector people are counting nanoseconds and they still rely on IP. IP, UDP and TCP aren't without problems when you need truly real time and low latency network performance - but then it probably doesn't make sense to use Ethernet to begin with. The sort of data rates and latency and sensitivity to jitter that we're talking about for typical CopperLAN usage doesn't even come close to maximizing the potential of IP.

So it just doesn't make sense...

I'm starting to suspect that what CopperLAN wants to do is to lock their users into an isolated platform so that the users will be forced to purchase CopperLAN-licenced technologies. This might not actually be a bad thing in itself but if the protocol is not IP-based (like ISCSI for instance) i think they're in for a bumpy ride.

Endosine wrote:
There is a large broadcast aspect to the protocol so I don't think having the router pass it would generally be a good thing. It's not intended to be a "over the Internet" thing, just a local area tool. The Jazzmutant Lemur and some other OSC devices often routed over UDP to get away from the overhead of TCP and help things be closer to real-time. The trade-off there was UDP has no handling of "lost packets" or handshaking, so if you are on a busy network UDP can have troubles.
Well the "problem with UDP" there is how the network infrastructure is set up. Set it up properly, and this will not be a problem. If you are overloading your network infrastructure and as a consequence are suffering from degraded performance, then you are doing something wrong.

I agree that sending data over the Internet is a bad idea if you care about the shape of your data once it's received. Still, why limit yourself?

Endosine wrote:
/past life as an IT guy
/current life as an IT guy who has to spend too much time thinking about this sort of bothersome stuff all day long :(


Endosine

It's possible they built it to lock people in, I don't really know their motives. I met with them at Musik Messe and I was asking them why this instead of OSC. They brought up the usual, no common definitions thing, but they didn't totally convince me.

With HFT they do have sub milisecond response times but they are also on fiber networks with high end modern routers and switches that are co-located with the data providers. A far cry from your average musician's home network with a $50 Linksys. Opposite ends of the network spectrum really. TCP/IP has a fair overhead and in my testing I've found going to UDP does improve the timing when you are relying on the network to deliver clock.

Someone is always coming up with something new, one of the great things about the modern age. At the end of the day if the Alyseum / CopperLAN setup solves someones problems it's a good thing to have them in the market.

The funniest part of the whole thing was the look on the Alyseum guys face when I asked him if he knew about Muff Wigglers...


daverj

Even if it's not what everybody fantasizes it could be, it still:

- uses a transformer isolated interface that can drive a signal across any room or stage without introducing any ground loops or hum

- uses a high speed interface that is orders of magnitude faster than midi

- uses a physical interface built into pretty much any computer made in the past 5 years, and many even older


poladark

I think it's cool hardware. That AL-88 MIDI interface/patchbay/merge looks nice as well.


mono-poly

Seems interesting.


CopperPhil

Well, I have some comments to post here :-)

mr chombee wrote:
Great module. I just wish it also had some CV/gate inputs.


We have prototyped a lot of things related to high resolution capture/rendering, and of course a "CV/Gate to CopperLan" board. We used it to demonstrate a Theremin controlling an analog synth through Ethernet cable (shown at Ircam, Paris). Do not know if Alyseum is planning to make such box, it'll probably depend on the success of its first products ;-)

Ankh wrote:
The product descriptions are bordering on too technical. So can this be used with say Silent Way, or is all it does convert MIDI to CV through some virtual MIDI port? Or is it something else entirely? seriously, i just don't get it


MIDI is translated to/from high resolution CopperLan messages. So it is possible to control CopperLan stuff from MIDI, and the opposite. CV devices are natively CopperLan, designed to handle high resolution/speed messages. So, controlling it from MIDI implies a 128 step resolution of course.

poladark wrote:
... There doesn't seem to be a public document specifying the protocol - yet they claim that the CopperLAN protocol is "open". Not using IP seems like a serious disadvantage. How are you supposed to use this with existing network infrastructure? Can i use my enterprise class Cisco switches and routers with CopperLAN? What if i want to collaborate with a person downstairs or in a different office? The advantage of using Ethernet with CopperLAN is not so obvious if I'd have to design a physically separate network to use it. ...


The CopperLan protocol is quite complex, far far away from implementing MIDI. It is plug&play, zero config, it provide automatic synchronization between control panels and remote devices, full setup save/restore, human friendly (everything is named), etc... so we offer to developers a complete framework with an important abstraction layer to facilitate CopperLan application programming. All the network management is automatically handled by the framework, developers just have to concentrate on their business without having to understand how it works inside. But, yes, CopperLan is "open" to the manufacturers through a consortium. We have to ensure the perenity of CopperLan, even we disappear. We do not want to lock the market, we are working for a long time to be able to offer a new unified communication solution for MI & pro-audio/sound & lights & everything on the stage. It's a private initiative, we do not depend on big manufacturers but we work with them for years to ensure that we have THE solution for their future needs. CopperLan is based on today's technology and is designed to evoluate, following the technical innovations while offering retrofit compatibility (as we did with MIDI). It is definitively not something to "lock" people with an expensive solution. CopperLan is cheap for manufacturers (and free if you make freeware) and development cost is reduced thanks to the framework doing most of the job.
Not using IP is something we decided a few years ago. CopperLan, it is 10 years of R&D. We tried a lot of things before the current implementation. We tried of course IP communication. But we leave it in order to be able to offer a real plug&play/no config/high performance network. The CopperLan Protocol can coexist with any other protocol on an Ethernet cable (even pro-audio) and do not need specific Ethernet hardware. It is based on MAC address, so yes indeed it can't pass through routers as is. But the target scope of CopperLan is a LAN, not a WAN. However it is possible to pass through VPN connection (after having enabled the protocol), but latency is usually too high for real-time performance (music) while it's ok for command/control/maintenance operations.

So this is my first pack of (long) comments :-) Do not hesitate if you have any question about CopperLan, I'm here to give you answers ;-)


CopperPhil

paults wrote:
I will make a guess the DAC is this part:

http://www.analog.com/static/imported-files/data_sheets/AD5629R_5669R. pdf

Which according to specs is ~ 14bit accuracy on average, could be 12-bits if you get a 'bad one'. Should be fine for most folks.

True 16-bit accurate DACs are about $15 each. For 1 output Dead Banana

You can of course mux that if you also hold the signal path to that accuracy over temp (which is also expensive, requires 0.1% low ppm resistors and low DC drift op amps like a AD822).


I can confirm that real 16 bits DAC are used in the MS-812.


CopperPhil

The MS-812 Emulator is available from the Alyseum web site (http://alyseum.com).

Feel free to download it, so you can try the product before buying! 8_)

The Emulator is running exactly the same code than the hardware MS-812, but you just have analog and digital output feedback from the graphical user interface, of course...

You can edit all the parameters from the CopperLan Manager's editor, and you can also try the free pitch (continuous scale instead of note based) with the XYController (http://sourceforge.net/projects/xycontroller/files). It is also possible to connect MIDI channels from to MS-812 performance inputs, same for clocks.

Let me know if you need additional information :-)


poppinger

CopperPhil wrote:
The MS-812 Emulator is available from the Alyseum web site (http://alyseum.com).


Very cool looking product.

However, I will never ever understand why people disable right-clicking on websites. It seems to exist solely to make a site more irritating to use.


withakay

Whilst I think this is cool and has some uses, I think for the average wiggler (or me, at least) it is a pretty expensive way to get a CV from your computer to your modular and at low midi resolution :(

For €399 you could pick up a cheap interface with adat or s/pdif and get an ES-3/4. With these options you get sample accurate timing and much higher resolution using your daw's automation and Silent Way DC versus sending 7 bit midi controllers.

The major benefits of the Aleyseum seem to be that you can use existing ethernet cables and run long cable lengths (as far as I can tell). Maybe I am missing the point...


withakay

If there were a module we could send 16bit signals to output as CV, that would change things imho Rockin' Banana!


AlyseumSupport

withakay wrote:
If there were a module we could send 16bit signals to output as CV, that would change things imho Rockin' Banana!

What is the data source you would like to connect ?
Because the MS-812 is precisely about receiving data in up to 16-bit resolution.


asterisk

let me get this straight.
if you use it in midi mode, resolution is limited to 128 steps right?
if you can use it in copperlan mode (which I'm still not sure how or what software to use as a controller on the computer) the resolution is very high and can accept lots of data and fast data?

max/msp object would be ideal for me to directly interface with copperlan. I hope someone runs with that.
to me this module seems pretty useless if you are just using it at midi resolution.....


A Dingleberry Monstrosity

that front panel is about as interesting as a bowl of chicken broth.

I LIKE ART


withakay

AlyseumSupport wrote:
withakay wrote:
If there were a module we could send 16bit signals to output as CV, that would change things imho Rockin' Banana!

What is the data source you would like to connect ?
Because the MS-812 is precisely about receiving data in up to 16-bit resolution.


Basically Silent Way for CopperLan.


jln

asterisk wrote:

max/msp object would be ideal for me to directly interface with copperlan. I hope someone runs with that.


I highly second that ! This would be great. Actually, this is the main reason I have been holding off going the CopperLan route.

(Alternatively), being able to send OSC-like message would be great.

Just my 2 wishes.

MUFF WIGGLER Forum Index -> Alyseum Goto page Previous  1, 2 [all]
Page 2 of 2
Powered by phpBB © phpBB Group