Schemas

dougcl · Post by **dougcl** » Sat Mar 10, 2012 3:03 pm

Hi folks, I am proposing the following module schema for the purpose of sharing module information between applications and databases. This is the place to provide feedback.

module.xsd:

Code: Select all

<?xml version="1.0" encoding="UTF-8"?> 
<xsd&#58;schema targetNamespace="http&#58;//www.hevanet.com/dougcl/rp/module.xsd" xmlns&#58;xsd="http&#58;//www.w3.org/2001/XMLSchema" xmlns&#58;tns="http&#58;//www.hevanet.com/dougcl/rp/module.xsd"> 
    <xsd&#58;element name="module" type="tns&#58;ModuleType"> 
   </xsd&#58;element> 
    <xsd&#58;complexType name="ModuleType"> 
       <xsd&#58;sequence> 
          <xsd&#58;element name="properties" type="tns&#58;ModulePropertiesType" minOccurs="1" maxOccurs="1"> 
      </xsd&#58;element> 
          <xsd&#58;element name="link" type="tns&#58;LinkType" minOccurs="0" maxOccurs="unbounded"> 
      </xsd&#58;element> 
       </xsd&#58;sequence> 
    </xsd&#58;complexType> 
    
    <xsd&#58;complexType name="LinkType"> 
       <xsd&#58;sequence> 
          <xsd&#58;element name="title" type="xsd&#58;string" minOccurs="0" maxOccurs="1"> 
      </xsd&#58;element> 
          <xsd&#58;element name="url" type="xsd&#58;string" minOccurs="1" maxOccurs="1"> 
      </xsd&#58;element> 
       </xsd&#58;sequence> 
    </xsd&#58;complexType> 

    <xsd&#58;complexType name="ModulePropertiesType"> 
        <xsd&#58;sequence>
        	<xsd&#58;element name="identifiers" type="tns&#58;IdentifierListType" minOccurs="0" maxOccurs="1">
        		<xsd&#58;annotation>
        			<xsd&#58;documentation>
        				List of database primary keys if available
					</xsd&#58;documentation>
        		</xsd&#58;annotation>
			</xsd&#58;element>
        	<xsd&#58;element name="timestamp" type="xsd&#58;string"
        		minOccurs="0" maxOccurs="1">
        		<xsd&#58;annotation>
        			<xsd&#58;documentation>
        				Used to version the module data
        			</xsd&#58;documentation>
        		</xsd&#58;annotation>
        	</xsd&#58;element>
        	<xsd&#58;element name="manuf" type="xsd&#58;string" minOccurs="1"
        		maxOccurs="1">
        		<xsd&#58;annotation>
        			<xsd&#58;documentation>
        				The module manufacturer eg. Doepfer
        			</xsd&#58;documentation>
        		</xsd&#58;annotation>
        	</xsd&#58;element>
        	<xsd&#58;element name="model" type="xsd&#58;string" minOccurs="1"
        		maxOccurs="1">
        		<xsd&#58;annotation>
        			<xsd&#58;documentation>
        				The module model. eg A-199
        			</xsd&#58;documentation>
        		</xsd&#58;annotation>
        	</xsd&#58;element>
        	<xsd&#58;element name="format" type="tns&#58;FormatType"
        		minOccurs="1" maxOccurs="1">
        		<xsd&#58;annotation>
        			<xsd&#58;documentation>
        				The module format. Restricted to specific
        				values. See below.
        			</xsd&#58;documentation>
        		</xsd&#58;annotation>
        	</xsd&#58;element>
        	<xsd&#58;element name="modifier" type="xsd&#58;string" minOccurs="0"
        		maxOccurs="1">
        		<xsd&#58;annotation>
        			<xsd&#58;documentation>
        				Optional additional module identifier. eg Rev2
        			</xsd&#58;documentation>
        		</xsd&#58;annotation>
        	</xsd&#58;element>
        	<xsd&#58;element name="HP" type="xsd&#58;positiveInteger"
        		maxOccurs="1" minOccurs="0">
        		<xsd&#58;annotation>
        			<xsd&#58;documentation>
        				The number of horizontal positions required by
        				the module.
        			</xsd&#58;documentation>
        		</xsd&#58;annotation>
        	</xsd&#58;element>
        	<xsd&#58;element name="mA" type="xsd&#58;positiveInteger"
        		maxOccurs="1" minOccurs="0">
        		<xsd&#58;annotation>
        			<xsd&#58;documentation>
        				Nominal current draw
        			</xsd&#58;documentation>
        		</xsd&#58;annotation>
        	</xsd&#58;element>
        	<xsd&#58;element name="V" type="xsd&#58;positiveInteger"
        		maxOccurs="1" minOccurs="0">
        		<xsd&#58;annotation>
        			<xsd&#58;documentation>
        				Nominal voltage at positive rail
        			</xsd&#58;documentation>
        		</xsd&#58;annotation>
        	</xsd&#58;element>
        	<xsd&#58;element name="priceUSD" type="xsd&#58;positiveInteger"
        		maxOccurs="1" minOccurs="0">
        	</xsd&#58;element>
        	<xsd&#58;element name="depth_mm" type="xsd&#58;positiveInteger"
        		maxOccurs="1" minOccurs="0">
        	</xsd&#58;element>
        	<xsd&#58;element name="moduleImageFilename" type="xsd&#58;string"
        		maxOccurs="1" minOccurs="0">
        	</xsd&#58;element>
        </xsd&#58;sequence>
    </xsd&#58;complexType> 

    <xsd&#58;simpleType name="FormatType"> 
       <xsd&#58;restriction base="xsd&#58;string"> 
          <xsd&#58;enumeration value="E"> 
             <xsd&#58;annotation> 
                <xsd&#58;documentation>Eurorack</xsd&#58;documentation> 
             </xsd&#58;annotation></xsd&#58;enumeration> 
          <xsd&#58;enumeration value="U"> 
             <xsd&#58;annotation> 
                <xsd&#58;documentation>Buchla</xsd&#58;documentation> 
             </xsd&#58;annotation></xsd&#58;enumeration> 
          <xsd&#58;enumeration value="S"> 
             <xsd&#58;annotation> 
                <xsd&#58;documentation>Serge</xsd&#58;documentation> 
             </xsd&#58;annotation></xsd&#58;enumeration> 
          <xsd&#58;enumeration value="M"> 
             <xsd&#58;annotation> 
                <xsd&#58;documentation>5U</xsd&#58;documentation> 
             </xsd&#58;annotation></xsd&#58;enumeration> 
          <xsd&#58;enumeration value="F"> 
             <xsd&#58;annotation> 
                <xsd&#58;documentation>Frac</xsd&#58;documentation> 
             </xsd&#58;annotation></xsd&#58;enumeration> 
          <xsd&#58;enumeration value="MM"> 
             <xsd&#58;annotation> 
                <xsd&#58;documentation>ModuleModule</xsd&#58;documentation> 
             </xsd&#58;annotation></xsd&#58;enumeration> 
          <xsd&#58;enumeration value="D"> 
             <xsd&#58;annotation> 
                <xsd&#58;documentation>Dotcom</xsd&#58;documentation> 
             </xsd&#58;annotation></xsd&#58;enumeration> 
          <xsd&#58;enumeration value="A"> 
             <xsd&#58;annotation> 
                <xsd&#58;documentation>Modcan A</xsd&#58;documentation> 
             </xsd&#58;annotation></xsd&#58;enumeration> 
          <xsd&#58;enumeration value="W"> 
             <xsd&#58;annotation> 
                <xsd&#58;documentation>Wiard 6U</xsd&#58;documentation> 
             </xsd&#58;annotation></xsd&#58;enumeration> 
          <xsd&#58;enumeration value="R"> 
             <xsd&#58;annotation> 
                <xsd&#58;documentation>Roland 100m</xsd&#58;documentation> 
             </xsd&#58;annotation></xsd&#58;enumeration> 
          <xsd&#58;enumeration value="E1"> 
             <xsd&#58;annotation> 
                <xsd&#58;documentation>Euro 1U Tile</xsd&#58;documentation> 
             </xsd&#58;annotation></xsd&#58;enumeration>
          <xsd&#58;enumeration value="MMM"> 
             <xsd&#58;annotation> 
                <xsd&#58;documentation>Mattson Mini Modular</xsd&#58;documentation> 
             </xsd&#58;annotation></xsd&#58;enumeration>
       </xsd&#58;restriction> 
    </xsd&#58;simpleType> 

    <xsd&#58;complexType name="IdentifierType">
    	<xsd&#58;sequence>
    		<xsd&#58;element name="authority" type="xsd&#58;string" minOccurs="1" maxOccurs="1"></xsd&#58;element>
    		<xsd&#58;element name="ID" type="xsd&#58;string" minOccurs="1" maxOccurs="1"></xsd&#58;element>
    	</xsd&#58;sequence>
    </xsd&#58;complexType>

    <xsd&#58;complexType name="IdentifierListType">
    	<xsd&#58;sequence>
    		<xsd&#58;element name="identifier" type="tns&#58;IdentifierType" minOccurs="1" maxOccurs="unbounded"></xsd&#58;element>
    	</xsd&#58;sequence>
    	
    </xsd&#58;complexType>
</xsd&#58;schema>

module.xml (example):

Code: Select all


<?xml version="1.0" encoding="ISO-8859-1"?> 
<module>
	<properties>
		<identifiers>
			<identifier>
				<authority>squiggletronics</authority>
				<ID>Z123456789</ID>
			</identifier>
		</identifiers>
		<manuf>Cwejman</manuf>
		<model>MX-4s</model>
		<format>E</format>
		<modifier>Rev2</modifier>
		<HP>20</HP>
		<mA>40</mA>
		<V>12</V>
		<priceUSD>775</priceUSD>
		<depth_mm>35</depth_mm>
		<moduleImageFilename>Cwejman_MX-4S.jpg</moduleImageFilename>
	</properties>
	<link>
		<title>Manufacturers Page</title>
		<url>http&#58;//cwejman.net/mx-4s.htm</url>
	</link>
	<link>
		<title>Muffs Wiki Page</title>
		<url>http&#58;//wiki.muffwiggler.com/MX-4S</url>
	</link>
</module>

The module zip filename standard is as follows:
manuf_format_model_modifier.zip

Example:
Cwejman_E_MX-4s_Rev2.zip

Note, the modifier part is optional and only used if needed.

a scanner darkly · Post by **a scanner darkly** » Tue Jul 10, 2012 4:55 pm

Perhaps we could discuss what should be added for patch points / knob definitions?

What I had in mind - 3 additional tags, inputs, outputs and controls.

Inputs / Outputs:
- type? (banana / minijack etc)
- name
- description (any description, such as purpose)
- position (relative to image top left corner)
- effective voltage range
- is it DC coupled

Controls
- type (pot, switch etc)
- name
- description

Not sure yet how to handle inputs / outputs / controls that change their function depending on other controls or what is plugged into the module.

Would be also useful to specify normalization somehow.

a scanner darkly · Post by **a scanner darkly** » Wed Jul 11, 2012 5:52 pm

Here is the revised schema that includes definition for inputs, outputs and controls - let me know what you think.
InputType and OutputType both inherit from InputOutputType in case new properties need to be added that are not shared by both inputs and outputs.

For normalization I included the normalizedTo element which should be the name of the input/output this element is normalized to.

Code: Select all

<xs&#58;schema attributeFormDefault="unqualified" elementFormDefault="qualified"
   targetNamespace="http&#58;//www.hevanet.com/dougcl/rp/module.xsd"
   xmlns&#58;tns="http&#58;//www.hevanet.com/dougcl/rp/module.xsd"
   xmlns&#58;xs="http&#58;//www.w3.org/2001/XMLSchema">
  <xs&#58;element name="module" type="tns&#58;module"/>
  <xs&#58;complexType name="module">
    <xs&#58;sequence>
      <xs&#58;element minOccurs="1" name="properties" type="tns&#58;ModulePropertiesType"/>
      <xs&#58;element minOccurs="0" maxOccurs="unbounded" name="link" type="tns&#58;LinkType"/>
    </xs&#58;sequence>
  </xs&#58;complexType>
  <xs&#58;complexType name="ModulePropertiesType">
    <xs&#58;sequence>
      <xs&#58;element minOccurs="1" name="manuf" type="xs&#58;string"/>
      <xs&#58;element minOccurs="1" name="model" type="xs&#58;string"/>
      <xs&#58;element minOccurs="1" name="format" type="tns&#58;FormatType"/>
      <xs&#58;element minOccurs="0" name="modifier" type="xs&#58;string"/>
      <xs&#58;element minOccurs="1" name="HP" type="xs&#58;positiveInteger"/>
      <xs&#58;element minOccurs="0" name="mA" type="xs&#58;positiveInteger"/>
      <xs&#58;element minOccurs="0" name="V" type="xs&#58;positiveInteger"/>
      <xs&#58;element minOccurs="0" name="priceUSD" type="xs&#58;positiveInteger"/>
      <xs&#58;element minOccurs="0" name="depth_mm" type="xs&#58;positiveInteger"/>
      <xs&#58;element minOccurs="1" name="moduleImageFilename" type="xs&#58;string"/>
      <xs&#58;element minOccurs="0" name="inputs" type="tns&#58;InputsType"/> 
      <xs&#58;element minOccurs="0" name="outputs" type="tns&#58;OutputsType"/>
      <xs&#58;element minOccurs="0" name="controls" type="tns&#58;ControlsType"/>
    </xs&#58;sequence>
  </xs&#58;complexType>
  <xs&#58;simpleType name="FormatType">
    <xs&#58;restriction base="xs&#58;string">
      <xs&#58;enumeration value="E"/>  <!-- Eurorack -->
      <xs&#58;enumeration value="U"/>  <!-- Buchla -->
      <xs&#58;enumeration value="S"/>  <!-- Serge -->
      <xs&#58;enumeration value="M"/>  <!-- 5U -->
      <xs&#58;enumeration value="F"/>  <!-- Frac -->
      <xs&#58;enumeration value="MM"/> <!-- ModuleModule -->
      <xs&#58;enumeration value="D"/>  <!-- Dotcom -->
      <xs&#58;enumeration value="A"/>  <!-- Modcan A -->
      <xs&#58;enumeration value="W"/>  <!-- Wiard 6U -->
    </xs&#58;restriction>
  </xs&#58;simpleType>
  <xs&#58;complexType name="LinkType">
    <xs&#58;sequence>
      <xs&#58;element minOccurs="0" name="title" type="xs&#58;string"/>
      <xs&#58;element minOccurs="0" name="url" type="xs&#58;string"/>
    </xs&#58;sequence>
  </xs&#58;complexType>
  
  <!-- inputs / outputs / controls -->
  <xs&#58;complexType name="ControlsType">
    <xs&#58;sequence>
      <xs&#58;element name="control" minOccurs="0" maxOccurs="unbounded">
        <xs&#58;complexType>
          <xs&#58;sequence>
            <xs&#58;element minOccurs="1" name="name" type="xs&#58;string"/>
            <xs&#58;element minOccurs="0" name="description" type="xs&#58;string"/>
            <xs&#58;element minOccurs="1" name="positionX" type="xs&#58;float"/>
            <xs&#58;element minOccurs="1" name="positionY" type="xs&#58;float"/>
            <xs&#58;element minOccurs="0" name="type" type="tns&#58;ControlType"/>
          </xs&#58;sequence>
        </xs&#58;complexType>
      </xs&#58;element>
    </xs&#58;sequence>
  </xs&#58;complexType>

  <xs&#58;simpleType name="ControlType">
    <xs&#58;restriction base="xs&#58;string">
      <xs&#58;enumeration value="pot"/>
      <xs&#58;enumeration value="switch"/>
      <xs&#58;enumeration value="joystick"/>
      <xs&#58;enumeration value="button"/>
    </xs&#58;restriction>
  </xs&#58;simpleType>

  <xs&#58;complexType name="InputOutputType">
    <xs&#58;sequence>
      <xs&#58;element minOccurs="1" name="name" type="xs&#58;string"/>
      <xs&#58;element minOccurs="1" name="description" type="xs&#58;string"/>
      <xs&#58;element minOccurs="0" name="jackType" type="tns&#58;JackType"/>
      <xs&#58;element minOccurs="1" name="positionX" type="xs&#58;float"/>
      <xs&#58;element minOccurs="1" name="positionY" type="xs&#58;float"/>
      <xs&#58;element minOccurs="0" name="DCCoupled" type="xs&#58;boolean"/>
      <xs&#58;element minOccurs="0" name="minV" type="xs&#58;float"/>
      <xs&#58;element minOccurs="0" name="maxV" type="xs&#58;float"/>
      <xs&#58;element minOccurs="0" name="normalizedTo" type="xs&#58;float"/>
    </xs&#58;sequence>
  </xs&#58;complexType>

  <xs&#58;complexType name="InputType">
    <xs&#58;complexContent>
      <xs&#58;extension base="tns&#58;InputOutputType" />
    </xs&#58;complexContent>
  </xs&#58;complexType>

  <xs&#58;complexType name="OutputType">
    <xs&#58;complexContent>
      <xs&#58;extension base="tns&#58;InputOutputType" />
    </xs&#58;complexContent>
  </xs&#58;complexType>

  <xs&#58;complexType name="InputsType">
    <xs&#58;sequence>
      <xs&#58;element name="input" type="tns&#58;InputType" minOccurs="0" maxOccurs="unbounded" />
    </xs&#58;sequence>
  </xs&#58;complexType>

  <xs&#58;complexType name="OutputsType">
    <xs&#58;sequence>
      <xs&#58;element name="output" type="tns&#58;OutputType" minOccurs="0" maxOccurs="unbounded" />
    </xs&#58;sequence>
  </xs&#58;complexType>

  <xs&#58;simpleType name="JackType">
    <xs&#58;restriction base="xs&#58;string">
      <xs&#58;enumeration value="minijack"/>
      <xs&#58;enumeration value="banana"/>
      <xs&#58;enumeration value="quarterinch"/>
    </xs&#58;restriction>
  </xs&#58;simpleType>

</xs&#58;schema>

BananaPlug · Post by **BananaPlug** » Fri Jul 13, 2012 8:09 am

A few comments about inputs, outputs and controls:

The list of control types is incomplete. Would it be better to have a "panel" node and then group controls, jacks, and other panel features under that? It could be extended to holes, cutouts, legends, indicators, etc.

As this schema gets bigger and bigger I start to see it working less well as a storage format. Perhaps the zip would have three files: image, moduleXML, panelXML

Not sure why you want to include AC/DC coupling info. Most jacks are DC coupled so if coupling is to be included I think that would be a better default.

Segregating the jacks into input and output types does not leave a way to represent a passive multiple or adapter. I'm not that familiar with XML "extension" but would these be "inputoutput" elements? There's at least one module out there with a jack which can be either an input or an output depending on a mode selection. It seems arbitrary to pick out signal direction as a type instead of it being merely another property of the jack. You have patching on your mind so I can see why you proposed it but I wonder if it's the best choice.

Other properties:

I'd like to see price dropped from the standard as the price is often set by dealers. Which price is it and how is this data maintained?

I'll post separately about a timestamp

BananaPlug · Post by **BananaPlug** » Fri Jul 13, 2012 8:30 am

Timestamp

Currently there is no way to know which of two zip files has more recent data. The date of the file becomes meaningless as files are copied from one system to another

For the Module Library (Version 2 - soon) I would like to include a UTC timestamp in the XML which indicates the time of the most recent change to anything in the XML and maybe the image but more on that below.

The basics are simple enough, when Library's editor saves to the database it checks to see if anything really changed and if there was a change the database will be updated and a timestamp tells us when that last happened. I'd like to put that in the XML the Library provides.

Changes to the image are also noted in Library's database. I could figure that into the general timestamp (use the newest one) or make it a separate "moduleImageTimestamp" property.

dougcl · Post by **dougcl** » Fri Jul 13, 2012 8:36 am

BananaPlug wrote:
I'd like to see price dropped from the standard as the price is often set by dealers. Which price is it and how is this data maintained?

I'll post separately about a timestamp

Just a note, the first post in this thread is the accepted version. I will update it as we go.

I can remove price, and I agree with you, but won't there just be pressure to put it back in again?

I like the separate panel.xml idea. I haven't given the whole panel details thing much thought, but it can easily get out of hand. We need to understand what the objective is, and start simple.

I would like to add the rack xml schema here, because I want to add "format" to it. This will help with Richy's multi format feature. Thoughts?

BananaPlug · Post by **BananaPlug** » Fri Jul 13, 2012 8:56 am

Doug,

I can remove price, and I agree with you, but won't there just be pressure to put it back in again?

For what it's worth nobody has ever complained that there's no way to enter a price in ModuleMaker. 15 of the 1300 or so modules in the database have prices.

Here's how I represent racks. I use this to make rack images. Richy must have something similar.

'sideways'=>'True if smallest modules in this format are wider than their height',
'formatx'=>'The increment for module size in x',
'formaty'=>'The increment for module size in y',
'edgeThickness'=>'Size of flange where mounting holes are',
'holeToEdge'=>'Distance from center of mounting hole to adjacent end of module',
'holeToEnd'=>'Distance from edge of rack opening to center of first module\'s first mounting hole',
'holeSpacing'=>'Distance between adjacent mounting holes (use an array for a repeating pattern)',
'holeDiameter'=>'Diameter of mounting hole');

$formatRails['Euro']=array(
'formatx'=>0.2,
'formaty'=>5.06,
'edgeThickness'=>0.27,
'holeToEdge'=>0.12,
'holeToEnd'=>0.1,
'holeSpacing'=>0.2,
'holeDiameter'=>0.1);

$formatRails['Frac']=array(
'formatx'=>1.5,
'formaty'=>5.25,
'edgeThickness'=>0.5,
'holeToEdge'=>0.3,
'holeToEnd'=>0.75,
'holeSpacing'=>1.5,
'holeDiameter'=>0.1);

$formatRails['ModuleModule']=array(
'sideways'=>1,
'formatx'=>1.43,
'formaty'=>4.25,
'edgeThickness'=>'',
'holeToEdge'=>'',
'holeToEnd'=>'',
'holeSpacing'=>'',
'holeDiameter'=>'');

$formatRails['5U']=array(
'formatx'=>1.75,
'formaty'=>8.75,
'edgeThickness'=>0.5,
'holeToEdge'=>0.25,
'holeToEnd'=>0.25,
'holeSpacing'=>array(1.25,0.5),
'holeDiameter'=>0.2);

a scanner darkly · Post by **a scanner darkly** » Fri Jul 13, 2012 2:55 pm

I like the idea of keeping panel XML as a separate file within zip. I agree that it should be simple at first (but I tried keeping it easily extendable). I think the main goals for panel specification would be:

1. providing information about location and type of nodes

This would be useful for applications that visualize patches. Another use case would be an application that prints patch sheets.

2. providing information about the purpose of each input/output/control

Easy way to document a module. Could build a set of applications to visualize it in different formats - printed cheat sheet, ipad quick reference app etc.

BananaPlug wrote:The list of control types is incomplete. Would it be better to have a "panel" node and then group controls, jacks, and other panel features under that? It could be extended to holes, cutouts, legends, indicators, etc.

Good point - I realized that when I started building the mapping tool. Will update the schema proposal.

BananaPlug wrote:Not sure why you want to include AC/DC coupling info. Most jacks are DC coupled so if coupling is to be included I think that would be a better default.

Not sure I understand correctly - are you saying that "DC Coupled" should be the default value since most jacks are? I think it's better to assume that if it's not specified then it's unknown. I made it a boolean property so that <DCCoupled>true</DCCoupled> would mean it is and so on. Not entirely happy about using a boolean here, perhaps enumeration of "yes" / "no" would be better? or have "coupled" property with "AC" / "DC" enumeration type?

BananaPlug wrote:Segregating the jacks into input and output types does not leave a way to represent a passive multiple or adapter. I'm not that familiar with XML "extension" but would these be "inputoutput" elements? There's at least one module out there with a jack which can be either an input or an output depending on a mode selection. It seems arbitrary to pick out signal direction as a type instead of it being merely another property of the jack. You have patching on your mind so I can see why you proposed it but I wonder if it's the best choice.

Good point. I agree that it makes more sense just to list all jacks and add a property that would specify whether it's an input, an output, or both. Will think about it some more.

There is also the case where control functions change depending on certain conditions (pot being an offset or attenuator depending on what's plugged would be a good example). Not sure how to specify conditions in this case, and if it's even necessary. Perhaps for each node there should be a list of functions with a text description for each? I think that might be overdoing it a bit, perhaps a simple text description is all that's really needed.

Also - would be good to include version number in module and panel XML in case future schema versions will become incompatible.

dougcl · Post by **dougcl** » Fri Jul 13, 2012 3:05 pm

I'm thinking module details aren't necessary to support Richy's current functionality. A new schema patch.xml (of Richy's design) stores the racks, the patch cords, and any notes or text on the patch. I think to support rack spanning patches, all we really need is to add a <format> and a <module_id> in rack.xml.

Later, as module details become available, applications can match up termination data in the patch to the module details based on X,Y values.

Doug

a scanner darkly · Post by **a scanner darkly** » Fri Jul 13, 2012 3:19 pm

Makes sense. Another reason to keep panel definitions in a separate file.

BananaPlug · Post by **BananaPlug** » Fri Jul 13, 2012 4:19 pm

Thanks folks. I think my timestamp suggestion got lost in all that so I'm calling your attention to it. I hope you will find it non-controversial and simple.

dougcl · Post by **dougcl** » Fri Jul 13, 2012 7:31 pm

Timestamp is a great idea. I'll add it.

Post by **Joe.** » Fri Jul 13, 2012 8:03 pm

awww, i was hoping this thread was about cultural schema's relating to the muffwiggler community

dougcl · Post by **dougcl** » Sat Jul 14, 2012 12:33 pm

LoFi Junglist wrote:awww, i was hoping this thread was about cultural schema's relating to the muffwiggler community

Isn't it? 8_)

dougcl · Post by **dougcl** » Fri Jul 27, 2012 12:47 am

Added timestamp to module.xml. I am now using Eclipse XML Tools so the result looks a little different. Hopefully this doesn't create a problem for anyone. One other change... I named the module type ModuleType instead of "module."

a scanner darkly · Post by **a scanner darkly** » Fri Sep 14, 2012 3:51 pm

After giving it more thought and building a mapping tool here is my revised proposal for the panel definition schema.

The main idea for the panel definition is to describe it as a set of nodes. Location and type are the main properties for each node, and then each node can have additional properties which depend on what type of node it is.

My reasoning here is that location and type of a node is what most applications would take advantage of. The rest of properties depends on what a particular application is aimed at.

Okay, now the proposal...

Panel definition should be in XML format and should live in a separate file (panel.xml) which would be part of module zip. Ideally it should use the same image file as the module definition (but doesn't have to).

PANEL DEFINITION SCHEMA

root:
schema version (mandatory)
timestamp (optional)
image file name (mandatory since node locations are tied to a particular image)
back image file name (optional, image of the back of the module)
front nodes (optional, typically ins/outs/controls/indicators/holes)
back nodes (optional, typically jumpers/trimmers/power+/power-)

each node:
name (optional)
type (optional, a string but the schema should define possible values, see below)
x (mandatory, x location relative to the image's top left corner)
y (mandatory, y location relative to the image's top left corner)
radius (optional, default value is used if not specified)
labelX (optional, position for node label)
labelY (optional, position for node label)
description (optional)
properties (optional, see below)

All coordinates and radius are float numbers between 0 and 1 which is pixel location divided by image width (for x, labelX and radius) or image height (for y and labelY).

For node types I propose the following:
jack
pot - a group encompassing controls that provide continuous fixed setting change (knobs, faders, trimmers)
switch - a group encompassing controls that provide discreet fixed setting change (buttons that change settings, switches, jumpers)
controller - a group encompassing any controls that are not fixed (expression controls - trigger buttons, ribbons, light sensors, motion sensors, touchplates etc)
indicator - a group encompassing any displays (LED, numeric, screen)
hole
power+
power-

For node properties the schema should allow easily adding new properties without versioning. The list of supported properties for each node type could be easily coordinated between app developers. This way new properties could be gradually added without breaking anything.

Properties would have the following format:
<property key="name">value</property>

At this point I would suggest properties only for the node type of jack:
signalDirection (in/out/either)
format (minijack/1/4"/banana etc, if not specified then it's a standard for this module format)
voltageRange (accepted voltage for inputs, output voltage for outputs)
coupling (AC/DC)
normalisedTo (name of the jack this one is normalised to)
attenuatedBy (name of the pot that controls attenuation)

Here is an example of panel definition XML:

Code: Select all

<module>
   <schemaVersion>1</schemaVersion>
   <timestamp>2012-09-13 02&#58;43&#58;16</timestamp>
   <moduleImageFilename>e340.jpg</moduleImageFilename>
   <backModuleImageFilename></backModuleImageFilename>
   <nodes>
      <node>
         <x>0.49675325</x>
         <y>0.43392858</y>
         <labelX>0.5064935</labelX>
         <labelY>0.57857144</labelY>
         <radius>0.10064935</radius>
         <type>jack</type>
         <name>density</name>
         <description></description>
         <properties>
            <property key="signalDirection">in</property>
            <property key="format">minijack</property>
         </properties>
      </node>
   </nodes>
   <backNodes/>
</module>

I can post Java classes and serialization code - let me know. To see panel definition files used in a context of an application (or to try and create your own map files!) see this thread: viewtopic.php?t=67777

dougcl · Post by **dougcl** » Sat Sep 15, 2012 11:15 pm

a scanner darkly wrote:After giving it more thought and building a mapping tool here is my revised proposal for the panel definition schema.

Seems like the idea is to call this panel.xml and add it to the module zip, right?

If so I think you're free to do whatever you think is right. You can continue fine tuning, because at this point you are the only one using this info. Once it is fully baked, I can add it to the first post here.

One thought I had though, if a patch planning application has a cable saved, it will likely know the start and end coordinates and the modules. Given a module, it would need to look in the zip and match up to a node based on the node location. For this reason, you might consider adding a "hit zone" area or something on each node to make it easier for apps to match cable terminations to nodes. Does that make sense?

Are the label positions needed?

EDIT: just looked at your app. Looks like the radius can be used to determine the hit area for cables.

BananaPlug · Post by **BananaPlug** » Sun Sep 16, 2012 8:13 am

I'm not sold on the node types and properties but that will straighten itself out as try it out with different modules.

a scanner darkly · Post by **a scanner darkly** » Sun Sep 16, 2012 12:07 pm

dougcl wrote:Seems like the idea is to call this panel.xml and add it to the module zip, right?

If so I think you're free to do whatever you think is right. You can continue fine tuning, because at this point you are the only one using this info. Once it is fully baked, I can add it to the first post here.

Yes, it makes sense to keep it in a separate file with its own schema I think. This way schemas can be developed independently without creating unnecessary dependencies for the apps that are not interested in that particular information. Judging from the latest Richy posts though I think he might be using similar panel definition, so I definitely want to get his input first.

dougcl wrote:EDIT: just looked at your app. Looks like the radius can be used to determine the hit area for cables.

You beat me to it - I was going to suggest using radius for that purpose. I also thought about being able to define node type - ellipse or rectangular and use width / height instead of radius, but it seems like an overkill. I think circles will work in 99% of the cases, and things that have really long rectangular shapes (power connectors) could be just marked by 2 nodes at each end (hence power+ and power- node types for power).

BananaPlug wrote:I'm not sold on the node types and properties but that will straighten itself out as try it out with different modules.

That's the part I'm least set on in my proposal. Playing with different modules definitely helps to get some ideas on how to group those.

The main idea behind node properties is that it will be easy to add them in such generic manner without breaking or versioning the schema. This would also help keeping properties when switching between different node types - if somebody made a mistake mapping a module all the relevant properties for the other node type will still be there (they just won't get used for other node types). The downside - property names would have to be coordinated to avoid duplicates, but that should be easy (and easier than updating the schema).

The ideas behind grouping nodes:

- jacks as a separate group I think is self explanatory? they are nodes that can be connected by a patch cable, and they have properties that do not apply to anything else (connector type, voltage range etc)

- controls are grouped to differentiate controls that are used to create a specific state (knobs, toggles, momentary buttons that change wavetable, for instance, etc) and performance controls - trigger buttons, ribbons. This way an app can take advantage of highlighting the nodes that define the state of a module, so additional properties could be defined for them that would allow storing that state.

- the rest is not grouped since different applications will use those node types differently or not use them at all (some will want to show screws over screw holes, some will ignore them, indicators are useful for apps that describe modules but not for patch editors etc).

dougcl · Post by **dougcl** » Mon Oct 15, 2012 7:34 pm

Added identifiers group to module properties to track database keys if available.

dougcl · Post by **dougcl** » Wed Oct 17, 2012 10:37 am

Added R to the format types for Roland 100m. Thanks RichyHo and bananaplug for making this happen.

dougcl · Post by **dougcl** » Wed Oct 17, 2012 1:13 pm

Added euro 1U tile format to support this:
http://erthenvar.com/store/index.php?ro ... ry&path=65

Thanks again to RichyHo and bananaplug for making this happen.

Busy day!

John Noble · Post by **John Noble** » Tue Oct 23, 2012 11:44 pm

OK, I'm now watching this topic for replies since there have been some additions I missed.

I've updated The Eurorack Database module file generator to include the new items. I'll repeat my comment from elsewhere about the advisability of including negative rail current and +5V current items since both can be very important to Eurorack users.

I'm including unique IDs for all modules now, and the "authority" is "eurorackdb". I omit the <link> element entirely if no link is present, and since I don't have a "title" for the information links I simply assign the generic string "Module Information". The link itself should be scrubbed of things that will make XML choke (ampersands, etc.).

Here's a sample for validation:

---------8<---------8<---------8<---------8<---------8<---------
<?xml version="1.0" encoding="ISO-8859-1"?>
<module>
<properties>
<identifiers>
<identifier>
<authority>eurorackdb</authority>
<ID>2</ID>
</identifier>
</identifiers>
<manuf>Make Noise</manuf>
<model>MATHS</model>
<HP>20</HP>
<format>E</format>
<mA>60</mA>
<V>E</V>
<priceUSD>280.00</priceUSD>
<depth_mm>24</depth_mm>
<moduleImageFilename>maths.jpg</moduleImageFilename>
</properties>
<link>
<title>Module Information</title>
<url>http://www.makenoisemusic.com/PATCHPAL.html</url>
</link>
<forum_url></forum_url>
</module>
---------8<---------8<---------8<---------8<---------8<---------

If this looks OK, I will take it live.

(Edit: wrong XML got pasted in for some reason.)

dougcl · Post by **dougcl** » Thu Oct 25, 2012 4:13 pm

Added Mattson Mini Modular format to schema.

MUFF WIGGLER

MUFF WIGGLER

Schemas

Schemas