Jump to content


Please note: You can easily log in to MPN using your Facebook account!

Present and Future Improvements to MIDI


tfort
 Share

Recommended Posts

SonicState has a post up about information coming out of the Audio Developers Conference held November 13-15 in London:

http://www.sonicstate.com/news/2017/11/17/new-midi-hd-features-outlined-at-adc/

 

The article links to video of a presentation by Ben Supper of Roli and MIDI.org, in which he discusses features being discussed for an updated MIDI specification.

 

From SonicState's article, these are some of the proposed features of "MIDI HD":

 

Main MIDI HD Features (preliminary and not set in stone)

MIDI Capability Enquiry - Improved device awareness - what are you?

Protocol negotiation

Profile configuration

Parameter exchange

Note attached parameters

More channels, controllers

Higher resolution for controllers

Bandwidth

Simplification of setting NRPN

Simplification Bank and program changes

 

It also seems the video contains all of the conference sessions. The conference schedule is here and contains some pretty interesting topics, if you want to find them in the video:

https://juce.com/adc-2017

Link to comment
Share on other sites



  • Replies 41
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Hasnt there been pretty regular speculation about a dramatic evolution for MIDI for ages now? Personally, Im all for it but a lot of stars need to align for it to happen.

 

I think the only sane way forward is to piggyback on successful mass-market technology that addresses most of the foundation needs. For me, USB is just a perpetuation of MIDIs most glaring flaw: the point-to-point topology. Sure, its bidirectional but its still a configuration mess not really geared toward devices acting as peers.

 

Give me gigabit Ethernet as a transport so all my devices talk to each other over a common bus. Every device is aware of any other device with peer-to-peer communication throughout. Build off of the prioritized traffic infrastructure that supports the likes of AVB, and let devices expose whatever individual protocols they support in a discoverable fashion. RTP-MIDI already defines the basics and its a free specification thats already supported by iOS and macOS.

Acoustic: Shigeru Kawai SK-7 ~ Breedlove C2/R

MIDI: Kurzweil Forte ~ Sequential Prophet X ~ Yamaha CP88

Electric: Schecter Solo Custom Exotic ~ Chapman MLB1 Signature Bass

Link to comment
Share on other sites

I get excellent resolution using 24bit Audio.

Any Module in my DSP Modular Based synthFX app from 1999 accepts Audio as a Modulation source.

This requires Expert Sleepers Silentway Suite 2.2.

 

MIDI Spec3 would be wise to incorporate it.

Ive got 0-16000 on every parameter and its much better than the (yawn) 0-128.

 

Its how I can get CV Audio quality.

Although my SE-02s use CV VCF In for CC# 74.

Great having such immediacy....

Magnus C350 + FMR RNP + Realistic Unisphere Mic
Link to comment
Share on other sites

I'm not in favor of killing all lively and poetically exciting artistic-technical efforts in favor of a bottom up approach to help technos to power. At all. Not even when "there is coverage". So if people want to play around with serial protocols to connect up musical instruments and software, that's fine, but taking an idea of an interface so out of it's technical solidness isn't.

 

Midi was and to some extend is a serial protocol and technology with standards about essential data, shared between manufacturers and some instrument specific data. That's readily understood, and of course it's nice if someone likes to keep track of some of the intrinsics in it.

 

There are limitations about the lower levels of the communications protocol, originally for sound reasons (for engineers), and there's a lack of formal definition about two of it's main intrinsic values of a communication protocol, delay and bandwidth. Especially the fixed (or as it sometimes is: the predictability) delay property would be something of interest.

 

The Closed Source-ness of the protocol over the last decades bothers me, though I understand the eagerness of some manufacturers to keep people from messing with the internals of their instruments.

 

T.

Link to comment
Share on other sites

It's pretty amazing to me that a spec developed for real-time performance in the early 1980s is still viable today. For shlubs like me that play gigs or sit at my kitchen table with a DAW and try to produce music, it's doing fine imo. But hell, let the pen-protector people loose and let's see what they can do! I'm sure they'll figure out a way to make it backwards-compatible with midi 1.0.
Link to comment
Share on other sites

Enough DC voltage to power any controller (like USB already has) would be a great midi spec improvement.

"It is a danger to create something and risk rejection. It is a greater danger to create nothing and allow mediocrity to rule."

"You owe it to us all to get on with what you're good at." W.H. Auden

 

Link to comment
Share on other sites

This is an interesting topic to me because there are many parallels in the Industrial world that I play in with my day job. I've been using MIDI for just a bit longer than I've been using industrial protocols and have dug fairly deeply into both.

 

In the industrial world HART was made in open protocol in 1986 and is still widely used today. It is a 2-way serial communication that is superimposed on a 4-20mA analog signal (think digital comm over the CV I/O of an analog synth). The initial intention was to remotely access and configure an instrument in the field by clipping onto the wires coming back to the control room. It became standard and people have been comfortable working with it for years.

 

But as technology advances, people began not only wanting to retrieve more diagnostic information from the field, but more process variables.....meaning even though I'm bringing in flow rate from a meter in the field, I know it also is measuring density, temperature, percent concentration, and other things....I want to bring them ALL back.

 

So for a while the HART protocol has been updated and people have tried to use it for more advanced applications, streaming HART variables (at about 1/2 second update rate, at best), and sending HART commands. Other protocols developed over the years that were faster but in many cases proprietary. Modicon PLC's talked Modbus, Siemens PLC's talked Profibus, Emerson promoted Foundation Fieldbus, Rockwell had DH+, Devicenet, Controlnet, and now Ethernet/IP. By the way, Yamah mLAN anybody? (See the parallels?). Another difference that could have implications in the music works is Deterministic vs Non-Deterministic. In the control world, the implication is that a protocol is specifically designed so that if somebody is transferring a large volume of diagnostic or configuration (maintenance) information, the bandwidth doesn't get interrupted such that a command to open or close a valve that is critical to the process doesn't get delayed. There is bandwidth dedicated at regular predetermined time intervals for control commands that cannot be interrupted. Faster protocols Thst are non deterministic end up working because they are so fast that it doesn't matter, but it still requires some engineering to look at how much data is passing through a switch for instance. The music equivilent could be making sure that a sysex dump doesn't affect latency of playing, as an example,

 

Over time, instrument manufacturers started offering multiple protocols to match up to whatever protocol was easiest to integrate into the control system. Much of what I've done lately is using protocol converters to match devices where we have holes in our offering. And yet still, HART from 1986 is the most widely used protocol..

 

Back to MIDI. The physical layer of DIN MIDI is a limitation to the protocol and even though USB is widely adopted, the ability to remain compatible with DIN is a limitation. I think the best solution would be a new ground up forward thinking protocol, possibly based on something like Ethernet as its physical layer, and develop protocol converters to address integration with legacy MIDI.

Dan

 

Acoustic/Electric stringed instruments ranging from 4 to 230 strings, hammered, picked, fingered, slapped, and plucked. Analog and Digital Electronic instruments, reeds, and throat/mouth.

Link to comment
Share on other sites

Back to MIDI. The physical layer of DIN MIDI is a limitation to the protocol and even though USB is widely adopted, the ability to remain compatible with DIN is a limitation. I think the best solution would be a new ground up forward thinking protocol, possibly based on something like Ethernet as its physical layer, and develop protocol converters to address integration with legacy MIDI.

 

I don't understand your point that midi over USB is crippled by the need to maintain comparability with midi over DIN and should discarded in favour of Ethernet.

 

According to midi.org USB 3 has the capacity to support transfer rates of 5GB/s. USB 2 is ubiquitous as an audio interface connector which involves transfer of vastly more data than the current midi 1 protocol requires.

 

Plus midi allows the slave USB devices to be powered by USB connection, one connection provides the convenience of power supply and data transfer.

 

Then there is the HD Protocol that has been developed by the Midi Manufacturers Association that is designed for use over USB or Ethernet. The HD Protocol caters for thousands of channels, high resolution controllers, time stamping, pitch and articulation data and to be backward compatible with the current Midi 1 protocol.

 

While Ethernet may be useful for studios and long runs at live shows in Stadiums or Arenas the humble USB and/or Thunderbolt 3 with USB-C ports are going to remain the most common connector on phones, tablets, laptops and computers for the foreseeable future.

 

MainStage 3 | Axiom 61 2nd Gen | Pianoteq | B5 | XK3c | EV ZLX 12P

Link to comment
Share on other sites

OK, let's back up. Most people don't understand the difference between the physical layer versus the protocol - very important distinction.

 

Let's back up and make sure everybody understands the difference between a physical layer and a protocol. The reason why you can do MIDI over USB is because people do the MIDI "Protocol" over the physical layer of "USB". One is a communication layer, they other is a protocol. They are different. One has to do with wires and how 1's and 0's are sent. They other is more like a language. I'm guessing most people don't understand this.

Dan

 

Acoustic/Electric stringed instruments ranging from 4 to 230 strings, hammered, picked, fingered, slapped, and plucked. Analog and Digital Electronic instruments, reeds, and throat/mouth.

Link to comment
Share on other sites

It's nice to know and to some extend have control over what messaging happens in a synthesizer and DAW. I prefer my 'drive shaft' to be with as little free play and torsion as is reasonably possible. Midi is a as simple as possible serial protocol from the start, with some intelligent added notions, and initially an Open Source message format and protocol (in fact initially not really a protocol). There are people who only want the message chain to allow all kinds of IT-like activities, including sloppiness, easy to program, no need for engineering ability concerning real time properties, and even AI-like behavior making people believe their software piano is going to make their interpretation of piano playing sound the greatest of all, and some even want simply to put their treacherous mark on the whole industry and leave it dead and miserably as a consequence.

 

I prefer to not need to know the protocol between keyboard and synth and virtual software instruments, which only happens when it is close to transparent, which requires an accuracy that all kinds of implementations do not achieve, and I know for a fact and to some extend can measure some don't even have that intention. I find that naive and bad engineering.

 

T.

Link to comment
Share on other sites

OK, let's back up. Most people don't understand the difference between the physical layer versus the protocol - very important distinction.

 

Let's back up and make sure everybody understands the difference between a physical layer and a protocol. The reason why you can do MIDI over USB is because people do the MIDI "Protocol" over the physical layer of "USB". One is a communication layer, they other is a protocol. They are different. One has to do with wires and how 1's and 0's are sent. They other is more like a language. I'm guessing most people don't understand this.

 

Thanks Dan, yes I understand the difference between a physical layer and a protocol which is why I referred to midi and HD "protocols".

 

My point was that USB is well capable of supporting the data transfer demands of the HD Protocol according to the Midi Manufacturers Association.

MainStage 3 | Axiom 61 2nd Gen | Pianoteq | B5 | XK3c | EV ZLX 12P

Link to comment
Share on other sites

OK, let's back up. Most people don't understand the difference between the physical layer versus the protocol - very important distinction.

 

Let's back up and make sure everybody understands the difference between a physical layer and a protocol. The reason why you can do MIDI over USB is because people do the MIDI "Protocol" over the physical layer of "USB". One is a communication layer, they other is a protocol. They are different. One has to do with wires and how 1's and 0's are sent. They other is more like a language. I'm guessing most people don't understand this.

 

Thanks Dan, yes I understand the difference between a physical layer and a protocol which is why I referred to midi and HD "protocols".

 

My point was that USB is well capable of supporting the data transfer demands of the HD Protocol according to the Midi Manufacturers Association.

 

Not directed towards you, just trying to offer insights into what I've seen over the years across industries, not just MIDI.

Dan

 

Acoustic/Electric stringed instruments ranging from 4 to 230 strings, hammered, picked, fingered, slapped, and plucked. Analog and Digital Electronic instruments, reeds, and throat/mouth.

Link to comment
Share on other sites

I thought it worth explaining for those who don't know the difference between a physical layer and a protocol. We have a wide range of folks on here. Everything from Theo, to Joe who just goes around breaking everything all the time.

Dan

 

Acoustic/Electric stringed instruments ranging from 4 to 230 strings, hammered, picked, fingered, slapped, and plucked. Analog and Digital Electronic instruments, reeds, and throat/mouth.

Link to comment
Share on other sites

I thought it worth explaining for those who don't know the difference between a physical layer and a protocol. We have a wide range of folks on here. Everything from Theo, to Joe who just goes around breaking everything all the time.

 

LOL

"Danny, ci manchi a tutti. La E-Street Band non e' la stessa senza di te. Riposa in pace, fratello"

 

 

noblevibes.com

 

 

Link to comment
Share on other sites

One of the reasons legacy MIDI has survived this long is that it's good enough for most people for most situations. It helps that they picked a nice robust connector, and that it's super cheap and easy to implement.

 

One should also not overlook the fact that it's opto-isolated. Raise your hand if you've ever had a ground loop caused by MIDI. I see no hands. Compare that to say, USB, which is notorious for causing ground loops and coupled EM noise on audio interfaces.

 

The reason that 5-pin DIN MIDI only runs at 31 kHz is because opto isolators were so slow 30 years ago. Simply by changing to a modern opto-isolator you can make 5-pin DIN MIDI run at much much higher bitrates.

 

I personally would like to see at least some flavor of 5-pin DIN MIDI live on. There are unused pins, so it's easy to envision some sort of bidirectional flavor with speed negotiation. So the default for any device is to poop out MIDI 1.1 as it's defined now, but add a system common speed negotiation message that gets sent periodically. Legacy devices would ignore it, and newer ones could send a message back up the pipe to negotiate to a higher bitrate and an expanded protocol.

 

While I do see the appeal of a more network-like implementation, to be honest I think this is overkill for the vast majority of MIDI users. We're dealing with musicians here. System complexity is something people should opt into, not out of.

Link to comment
Share on other sites

One of the reasons legacy MIDI has survived this long is that it's good enough for most people for most situations. It helps that they picked a nice robust connector, and that it's super cheap and easy to implement.

 

One should also not overlook the fact that it's opto-isolated. Raise your hand if you've ever had a ground loop caused by MIDI. I see no hands. Compare that to say, USB, which is notorious for causing ground loops and coupled EM noise on audio interfaces.

 

The reason that 5-pin DIN MIDI only runs at 31 kHz is because opto isolators were so slow 30 years ago. Simply by changing to a modern opto-isolator you can make 5-pin DIN MIDI run at much much higher bitrates.

 

I personally would like to see at least some flavor of 5-pin DIN MIDI live on.

Midi over USB is notorious for midi ground hum - where is the evidence? How about 'raise your hands if you have experienced midi over USB ground loop hum'?

 

Midi over USB has been used by EDM, Hip hop and other electronic bands live and in the studio for over 10 years, just as it is by every tablet or phone music app. Plus all those live muso's using controllers and laptops. There are probably at least 20 of those who regularly post here. No mention of midi ground issues.

 

The issue of USB ground hum was recently raised here in a thread about how well a forumites laptop rig was working for him.

 

2 cases were offered as examples. One of those was using an old Yamaha board and the other using a PX-5S. These two both require their own power supply. A faulty component in the Yamaha given the age of the board when the issue arose was not ruled out, neither was plain poor design, as its primary purpose was not for use as a midi over USB controller.

 

In the case of the PX-5S Mike Martin responded saying the attached computer was faulty. Given Mike's reputation and the fact that others here use a PX-5S as a controller with zero midi ground hum issues everything points to a faulty or poorly designed computer.

 

Sure there is the possibility that it could occur, but the incidence seems to be so low it approachs zero, and attributable to poor design or component failure, no different then to the primary cause of failure in hardware boards.

 

Same goes for EM noise on USB audio interfaces. USB is the most widely used connection available in an audio interface.

 

If USB induced EM noise is notorious and widespread then the market for these would be dead by now. Companies like Focusrite, RME, Radial and 30 or more others would have long ago abandoned USB audio interfaces or gone out of business.

 

DIN will have a life as a midi connector from the day Apple and Microsoft redesign their tablets, laptops and phones to incoporate a DIN port. Otherwise it will live on as a connector between hardware boards where some or all of the additional control items available in the HD Protocol are not required.

 

On the other hand innovative controller manufacturers continue to embrace midi over USB 2, for example the Roli Seaboard Rise and Grand or the more traditional Kawai VPC1.

 

None of this would be happening if midi or audio over USB were notorious for ground loop hum and EM noise.

MainStage 3 | Axiom 61 2nd Gen | Pianoteq | B5 | XK3c | EV ZLX 12P

Link to comment
Share on other sites

Another difference that could have implications in the music works is Deterministic vs Non-Deterministic. In the control world, the implication is that a protocol is specifically designed so that if somebody is transferring a large volume of diagnostic or configuration (maintenance) information, the bandwidth doesn't get interrupted such that a command to open or close a valve that is critical to the process doesn't get delayed.

 

That's precisely what the real-time extensions to Ethernet's layer 2 do for AVB and RTP-MIDI. They allow guaranteed bandwidth to be reserved without the risk of collisions and retries, and whatever's left is used according to normal IP traffic management rules.

 

Back to MIDI. The physical layer of DIN MIDI is a limitation to the protocol and even though USB is widely adopted, the ability to remain compatible with DIN is a limitation. I think the best solution would be a new ground up forward thinking protocol, possibly based on something like Ethernet as its physical layer, and develop protocol converters to address integration with legacy MIDI.

 

That's what RTP-MIDI already provides. It has been built into macOS since 10.4 more than a decade ago, and it interoperates nicely with AVB to carry audio over the same physical transport. What we need isn't the standard, but to have the rough edges filed off over the course of widespread adoption.

Acoustic: Shigeru Kawai SK-7 ~ Breedlove C2/R

MIDI: Kurzweil Forte ~ Sequential Prophet X ~ Yamaha CP88

Electric: Schecter Solo Custom Exotic ~ Chapman MLB1 Signature Bass

Link to comment
Share on other sites

Just like with audio, I'd prefer Midi to be (in some sense "satay") reliable and well specified. Much is lacking in those departments, even though there is basic functionality. For instance, Usb protocols can easily be unreliable, especially so in unforeseen constellations of software and electronics (testing is horribly complex), the response from software to failure (cmp. reading a volume bit wrong, stuck notes when connection fails, etc) isn't always well thought through for pro use, and there's a lot of protocol stuff, including OSC, where data verification and the rule over the reliable functioning is shallow, to say the least.

 

The idea of passing data over a wire with loose or specific real time control isn't a new one, intercontinental automatic telephone exchange units do this since the 60s or so, but to make it work in all kinds of circumstances and making it reliable for customers isn't an easy sports, electronically and data-theoretically speaking. So something like a serial interface (around since long before the early PCs, with "interesting" standard issues) with a recognizable protocol, with forms of redundancy and control over failure (standard bit and message patterns, panic commands (all notes off), connection verification (active sensing) is logical. This doesn't translate well to the modern age with software flakiness and networking basics, especially at the level of software engineering. That's ok for hobbying around, and relatively awarding in terms of ROI. It's another thing to set up pro systems that need to prevent certain errors, from enforcing character on the music to controlling loudness in the face of error.

 

T.

Link to comment
Share on other sites

 

None of this would be happening if midi or audio over USB were notorious for ground loop hum and EM noise.

 

Disconnect a usb cable, hum goes away; Therefore it must be the the transmitting or receiving device that's at fault, right? Where it's easy to think you just eliminated your ground loop often times what you end up doing is changing the current path, and in doing so may have temporarily reduced or eliminated the hum. Same for using those AC filters (HUMx etc.) or even swapping outlets. The ground loop is still there and any number of things can change the current path again resulting in hum.

 

That's why you need to look at the whole system and ensure there are no dual ground paths, cable shields often being the culprit.

It's easy to overlook something and while it seems easy, it's often a very difficult problem to solve.

 

Link to comment
Share on other sites

With gigabit Ethernet as a transport your bandwidth would be more than 30 thousand times greater than the original MIDI hardware. Given a mere thousand times the bandwidth, a fraction of what we could have, the lag between receiving multiple note on events would be a microsecond instead of a millisecond. Chances are the synth would pick up an entire packet and process it together so all notes in a chord could actually play in perfect synchronization - presuming you played it that way, which isnt likely, or quantized / programmed it to be simultaneous.

Acoustic: Shigeru Kawai SK-7 ~ Breedlove C2/R

MIDI: Kurzweil Forte ~ Sequential Prophet X ~ Yamaha CP88

Electric: Schecter Solo Custom Exotic ~ Chapman MLB1 Signature Bass

Link to comment
Share on other sites

...it's easy to envision some sort of bidirectional flavor with speed negotiation. So the default for any device is to poop out MIDI 1.1 as it's defined now, but add a system common speed negotiation message that gets sent periodically. Legacy devices would ignore it, and newer ones could send a message back up the pipe to negotiate to a higher bitrate and an expanded protocol.

 

While I do see the appeal of a more network-like implementation, to be honest I think this is overkill for the vast majority of MIDI users. We're dealing with musicians here. System complexity is something people should opt into, not out of.

 

In the video, the group developing MIDI HD are proposing just such a scenario: upon connection, one side will attempt to negotiate a high-speed connection, and if that is not recognized will fall back to MIDI 1.1.

 

I think the benefits of using the huge established base of technology from ethernet networking and applying that with real-time guarantees to digital audio is quite compelling. It's interesting that when this is possibly on the near-term horizon that computers (okay, Macs) are no longer including an ethernet port and instead going only to multi-protocol USB-C/Thunderbolt 3 connectors.

 

From instrument to computer, it seems USB3.1 might be more advantageous, while for multiple stage instruments to mixer an ethernet-based protocol is preferable. Thunderbolt could support many protocols and use scenarios, but won't achieve the near-ubiquity of USB and ethernet and TB cables are more expensive. All of those can potentially offer power. Current USB and USB/Thunderbolt offer up to 100 watts of power, while Power Over Ethernet offers only 25 watts.

 

PoE may be able to offer more in the near future, however: "The upcoming IEEE 802.3bt[10] aka 4PPoE (4 Pair Power over Ethernet) standard slated for early 2018 will introduce two additional power types: up to 55 W (Type 3)and up to 90-100 W (Type 4). Each pair of twisted pairs will need to handle a current of up to 600 mA (Type 3) or 960 mA (Type 4).[11] Additionally, support for 2.5GBASE-T, 5GBASE-T and 10GBASE-T is planned." (Wikipedia article on PoE)

Link to comment
Share on other sites

Depending on the kind of wired network, and the practical traffic control of a switch/hub/router ping times aren't quite there yet to do sample accurate transfers, and the lag time in the packet processing kernel and network modules may be considerable even though additional payload wouldn't be a prob from some Midi tracks. How far does a PC or Mac get to actually give you full bandwidth, and, how is the maximum latency ? Most OSes aren't very good at real time stuff yet, which is ok for some experiments, but a reliable instrument might demand more. Getting an over all controller to proper software response that jitters less than a millisecond is probably hard to do in a lot of sub ideal circumstances and with realistic measurement. That's gonna make some instrument properties like mid frequency ensembles sound shitty when play staccato. For single notes, the original midi protocol can be way less jittery, with fixed delay.

 

T

Link to comment
Share on other sites

Let me take it a step further....what about Video + Audio + MIDI in one protocol all synced? Sort of like HDMI + MIDI.

Dan

 

Acoustic/Electric stringed instruments ranging from 4 to 230 strings, hammered, picked, fingered, slapped, and plucked. Analog and Digital Electronic instruments, reeds, and throat/mouth.

Link to comment
Share on other sites

Individually, those are sort of synchronous data transfer protocols, that's advantageous.

 

There are USB isolators, at the very least I've seen one at Olimex, which puts the ground separation behind us under the condition that it works.

 

It's kind of not all right with me to drive a big power rig from a single Usn connection. I drive in the order of a kilowatt myself from a (ground isolated, well controlled) Usb interfaced quality DAC with synchronous clock control, but it's like on a tour or something, with the band and stuff, that little connector to those power banks, you know, shouldn't that rather be a metal plug with thread and cap and so on ?

 

T.

Link to comment
Share on other sites

Depending on the kind of wired network, and the practical traffic control of a switch/hub/router ping times aren't quite there yet to do sample accurate transfers, and the lag time in the packet processing kernel and network modules may be considerable even though additional payload wouldn't be a prob from some Midi tracks.

 

The RTP extensions at layer 2 of the Ethernet protocol are a key part of AVB. They provide guaranteed transfer windows to avoid the variable latency of packet transmission with classic TCP/IP and can provide surprisingly low latency:

 

MOTU AVB devices use Gigabit Ethernet and clever engineering to achieve a fixed latency over seven hops of less than a millisecond point-to-point in the network at a 48kHz sample rate, including the combined contributions of network, interface, and processor.

 

As usual, the driver model of the host OS you connect it to will still be a factor and isnt likely to be optimized for this task, but its still extremely promising.

Acoustic: Shigeru Kawai SK-7 ~ Breedlove C2/R

MIDI: Kurzweil Forte ~ Sequential Prophet X ~ Yamaha CP88

Electric: Schecter Solo Custom Exotic ~ Chapman MLB1 Signature Bass

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...