I added the ASM Hydrasynth to a github repository.
My intention is to add more definition files as they appear on the forum - feel free to help out 
Edit: I removed the repository (and the link to it) following these insights
14 Likes
This is great!
2 Likes
great idea!
1 Like
Iām no github pro, but I added octatrack, dominion 1 and tanzbar (ccs). I have a few more I just put together, but I canāt seem to make directories. 
Iāll add here.
And gotta say, Iām so psyched to finally be able to control Tanzbar this way.
VERSION 1 # Currently, this should only be 1.
# Supports all alphanumeric ASCII, and ' ', '_', '-', '+' - can also be NULL
TRACKNAME Tracker
# Can be POLY, DRUM, MPE, or NULL
TYPE NULL
# Can be A, B, C, D, USBD, USBH, CVGx (x between 1&4), CVx, Gx, or NULL
OUTPORT A
# Can be x (between 1-16), or NULL -- this is ignored if output port is not MIDI
OUTCHAN 16
# Can be NONE, ALLACTIVE, A, B, USBH, USBD, CVG, or NULL
INPORT NULL
# Can be x (between 1-16), ALL, or NULL. This definition will be ignored if INPORT is NONE, ALLACTIVE or CVG
INCHAN NULL
# DRUMLANES
# Syntax ROW TRIG CHAN NOTENUMBER NAME
# ROW must be between 1 and 8
# TRIG can be between 0 and 127, or NULL
# CHAN can be a number between 1 and 16, Gx, CVx, CVGx (x between 1 and 4), or NULL
# NOTENUMBER can be between 0 and 127, or NULL
# NAME supports all alphanumeric ASCII, and ' ', '_', '-', '+' - can also be NULL
# Please note this section will be discarded for tracks which are not DRUM tracks
[DRUMLANES]
[/DRUMLANES]
# PC
# Syntax NUMBER NAME
# number must be either
# - A number (for simple PC)
# - Three numbers, delimited by ' ', which represent PC MSB LSB. You can put 'NULL' to not set the MSB/LSB.
# PC must be between 1...128
# MSB/LSB must be between 0...127
[PC]
[/PC]
# CC
# Syntax CC_NUMBER NAME or CC_NUMBER DEFAULT=xx NAME
# DEFAULT_VALUE must be a valid number between 0 and 127
[CC]
0 BANK_SELECT
7 VOLUME
79 DELAY_MIX
80 REVERB_MIX
81 DRY_MIX
82 LINE_INPUT
41 1_PerfTrkCh
42 2_PerfTrkCh
43 3_PerfTrkCh
44 4_PerfTrkCh
45 5_PerfTrkCh
46 6_PerfTrkCh
47 7_PerfTrkCh
48 8_PerfTrkCh
51 01_PerFX
52 02_PerFX
53 03_PerFX
54 04_PerFX
55 05_PerFX
56 06_PerFX
57 07_PerFX
58 08_PerFX
59 09_PerFX
60 10_PerFX
61 11_PerFX
62 12_PerFX
71 01_MastMxVol
72 02_MastMxVol
73 03_MastMxVol
74 04_MastMxVol
75 05_MastMxVol
76 06_MastMxVol
77 07_MastMxVol
78 08_MastMxVol
79 09_MastMxVol
80 10_MastMxVol
81 11_MastMxVol
82 12_MastMxVol
[/CC]
# NRPN
# Syntax "MSB LSB DEPTH NAME" or "MSB LSB DEPTH DEFAULT=xx NAME"
# Lsb & msb should be between 0 and 127
# DEPTH can be 7 or 14
# For NRPN DEFAULT_VALUE must be a valid number, either between 0 and 127 (for 7 bit NRPNs) or between 0 and 16383 (for 14bit NRPNs)
[NRPN]
[/NRPN]
# ASSIGN
# Syntax POT_NUMBER TYPE VALUE or POT_NUMBER TYPE VALUE DEFAULT=DEFAULT_VALUE
# POT_NUMBER must be between 1 and 8
# TYPE can be "CC", "PB" (pitchbend), "AT" (aftertouch), "CV", "NRPN", or "NULL" (this won't assign the pot).
# Non explicitly-defined pots will be considered "NULL"
# VALUE VALIDATION
#### For CC Value must be a valid number between 0 and 119
#### For PB and AT, any text after the TYPE will be ignored
#### For CV, value must be between 1 and 4
#### For NRPN, value must be MSB LSB DEPTH, with both lsb & msb bebtween 0 and 127, and DEPTH being either 7 or 14
# DEFAULT VALUE
#### For CC DEFAULT_VALUE must be a valid number between 0 and 127
#### For PB DEFAULT_VALUE must be a valid number between 0 and 16383
#### For NRPN DEFAULT_VALUE must be a valid number, either between 0 and 127 (for 7 bit NRPNs) or between 0 and 16383 (for 14bit NRPNs)
#### For CV DEFAULT_VALUE must be either a valid number between 0 and 65535, or a voltage between -5V and 5V, e.g. "-4.25V" or "1.7V"
#### Please note default value will be ignored for PB and AT messages.
[ASSIGN]
[/ASSIGN]
# AUTOMATION
# Syntax TYPE VALUE
# TYPE can be "CC", "PB" (pitchbend), "AT" (aftertouch), "CV", or "NRPN"
# VALUE VALIDATION
#### For CC Value must be a valid number between 0 and 119
#### For PB and AT, any text after the TYPE will be ignored
#### For CV, value must be between 1 and 4
#### For NRPN, value must be MSB LSB DEPTH, with both lsb & msb bebtween 0 and 127, and DEPTH being either 7 or 14
[AUTOMATION]
[/AUTOMATION]
# This section will be readable from Hapax.
[COMMENT]
BETA by Phil 20220711
[/COMMENT]
------------
VERSION 1 # Currently, this should only be 1.
TRACKNAME Per4mer MKII
TYPE POLY
OUTPORT A
OUTCHAN NULL
INPORT NONE
INCHAN ALL
# PC
# Syntax: NUMBER NAME
# number must be either:
# - A number (for simple PC)
# - Three numbers, delimited by ':', which represent PC:MSB:LSB. You can put 'NULL' to not set the MSB/LSB.
# PC must be between 1...128
# MSB/LSB must be between 0...127
[PC]
1 INIT
1:1:NULL BANKB_PATCH2 #for the blofeld, MSB sets the bank, PC sets the patch
[/PC]
# CC
# Syntax: CC_NUMBER NAME or CC_NUMBER:DEFAULT=xx NAME
# DEFAULT_VALUE must be a valid number between 0 and 127
[CC]
1 MOD_WHEEL
3 MOD_RATE
4 AFTERTOUCH
5 PORT_TIME
7 VOLUME
65 PORT_ONOFF
68 LEGATO
84 PORT_MOD
[/CC]
# This section will be readable from Hapax.
[COMMENT]
BETA by Phil 20220711
[/COMMENT]
------------------
VERSION 1 # Currently, this should only be 1.
TRACKNAME OB-6
# Can be POLY, DRUM, MPE, or NULL
TYPE POLY
# Can be A, B, C, D, USBD, USBH, CVGx (x between 1&4), CVx, Gx, or NULL
OUTPORT A
# Can be x (between 1-16), or NULL -- this is ignored if output port is not MIDI
OUTCHAN 13
# Can be NONE, ALLACTIVE, A, B, USBH, USBD, CVG, or NULL
INPORT NONE
# Can be x (between 1-16), ALL, or NULL -- ignored if INPORT is NONE, ALLACTIVE or CVG
INCHAN ALL
# PC
# Syntax: NUMBER NAME
# number must be either:
# - A number (for simple PC)
# - Three numbers, delimited by ':', which represent PC:MSB:LSB. You can put 'NULL' to not set the MSB/LSB.
# PC must be between 1...128
# MSB/LSB must be between 0...127
[PC]
1 INIT
1:1:NULL BANKB_PATCH2 #for the blofeld, MSB sets the bank, PC sets the patch
[/PC]
# CC
# Syntax: CC_NUMBER NAME or CC_NUMBER:DEFAULT=xx NAME
# DEFAULT_VALUE must be a valid number between 0 and 127
[CC]
0 BkSelMSB
1 ModWheel
3 BPM
4 FootCtr
5 PortTime
6 DtEntMSB
7 MIDIvol
8 SbOctLvl
9 DstortAm
38 DtEntLSB
39 VolumLSB
40 VCAEnvAm
41 VCAEnVel
43 VCAEnvAt
44 VCAEnvDe
45 VCAEnvSu
46 VCAEnvRe
47 FtrEnvAm
50 FtrEnvAt
51 FtrEnvDe
52 FtrEnvSu
53 FtrEnvRe
58 ArpOnOff
59 ArpMode
60 ArpOctav
62 ArpClDiv
64 DamprPed
65 PmtoOnOf
67 Osc1Freq
69 Osc1Levl
70 Osc1Shap
71 Osc1PW
74 Brigtnes
75 Osc2Freq
76 Osc2Detn
77 Osc2Levl
78 Osc2Shap
79 Osc2PW
96 DataIncr
97 DataDecr
98 NRPNPLSB
99 NRPNPMSB
100 RPNPLSB
101 RPNPMSB
102 FiltrFrq
103 FiltrRes
104 FtrKeyAm
105 FtVlOnOf
106 FltrMode
107 BP OnOff
120 AlSendOf
121 ResetCon
122 LcCnOnOf
123 AlNotsOf
124 OmiMdeOf
125 OmiMdeOn
126 MonMdeOn
127 PlyMdeOn
[/CC]
# This section will be readable from Hapax.
[COMMENT]
BETA by Phil 20220711
[/COMMENT]
I found out how to do it in the browser by accident.
If you create new file and type a / into the Name your fileā¦ input, it will turn whatever text is before the / into a directory. In other words, typing elektron/octatrack.txt will create the directory elektron and the file octatrack.txt. 
oK. I added the directories and files. Looks like it requires approval to show up.
great initiative
two suggestions, given the definitions are supplied by the communityā¦
a) add a license to the GitHub repo for clarity.
Id suggest MIT given its most permissive.
b) add a reference back to source.
perhaps in the comments, include a link to the topic on this forum from which the definition came. this will help if the definition is updated, and also be clear who did the work on creating the definitionā¦ credit where its due.
4 Likes
Now this is a topic I purposely know very little of but does this imply people claim to be creators of some sort of work in making these instrument definitions?
I think Iād rather just keep the repo private than decide on a copyright thing tbh.
It is a shame as it goes against the communal aspect of sharing definition files.
I agree on the tracability aspect, but to me it would have been preferable if some version control system was the source of truth and the forum referenced that, instead of the other way around.
claim to be creators of work ?
they are the creators , and put in some work to create ā¦ no āclaimā about it.
(some definitions could well take quite a bit of effort to create)
they are simply sharing, and putting into the public domain.
of course, in this case, no one really cares - its not a legal thing really.
but I do think given credit, linking to the source is important.
the issue with no license, is its very unclear (btw: copyright != licence, two different things)
of course, I fully accept that I (nor others here) ā¦ cannot speak on behalf of everyone thats sharing definitions, and so what they think is reasonable, or if they careā¦
and, of course, different contributors may have different ideas too
I think thats a pretty moot pointā¦ something you could discuss with Squarp.
also I think having it on the āofficialā site makes it much more visible,
itās sensible that it should be on a site under the control of Squarp.
as devs, should we love VCS, but honestly its too much for many users,
and a community effort like this, its important contributions are easy.
(Ive some experience of trying to get users to use git, doesnāt work out well 
)
however, I do like the ideaā¦ just itās not really viable as the primary way to do it.
its a pity it has to be a manual effort thoughā¦ as thats not going to scale well.
(Pyramid ended up with alot of instrument definitionsā¦ and hapax will be the same)
anyway, these were just suggestions
1 Like
The URL in the OP gives a 404. Has the repo been (re)moved?
Yes, it made little sense to keep it public given the above discussion.
I felt it added to the complexity of contributing and consuming instrument definitions, as opposed to reducing it.
I will add a note to the initial post.
Thatās a bummer, I thought it was helpful having them all in one place rather than scattered around on a forum.
I hope youāre willing to reconsider, please donāt let a mere suggestion to comply with this bizarre trend to append vacuous legalese that no one bothers to read anyway discourage you from adding something useful to the internet. It was made for sharing after all, not for the satisfaction of some imagined compliance department.
3 Likes
or anyone who creates an instrument definition file to post on the Squarp forums could just add waiver language to their post, that others have permission to repost/re-use freely etc (if they even care that much about it)
I donāt see why an instrument definition git repo would not work, however it would require the following elements to be very useful to the community:
-
One or more maintainers who accept PRs and changes to the āmainā repo. Could be anyone, but needs to be active.
-
A simple validation script to check syntax.
-
Someone from Squarp to grant a permissive license for: https://beta.squarp.net/hapax/instr_def/template.txt ā could be MIT/GPL/etc. or could be a CC NC license.
Could also benefit from a āplain HTMLā site indexing the various definitions files.
I will write (2) next time I have a spare moment.
6 Likes
totally agreeā¦ a repo is just a storage mechanism.
I merely made suggestions, that are inline with taking someones efforts from one place, and putting them somewhere elseā¦ not quite sure what the OP had against this.
I think ideally (and we dont live in an ideal world) :
a) Squarp owner of repo
they could create it, setup the licence etc , and appoint community maintainers to accept PRs
b) instrument definition license
as you say @RogerMexico , something in the template and/or on this forum to make it clear sharing is ok. I donāt see anyone having an issue with this, but its important to be clear
I donāt think validation is really an issue - people can already publish non-working instrument definitions here, so why put an extra onus on the repo?
however, I think there are three important āissuesā with using a repo
(in priority order)
a) entry level to sharing is super low on forum
many users do not know how to use Git/Github (and wont want to learn)
posting on this forum is easy, no extra accounts, no extra skills.
b) entry level to accessing is low on the forum, also commenting
again, not many use git/githubā¦ whereas most users use this forum.
also the forum, allows for comments/discussions, which is a useful side that git cannot really support.
(seriously, lets not start talking about git issues )
c) two sources for instrument defs
this creates an issue of WHERE is the primary source of instrument definitions.
you do NOT want to split these over two places, its now two places to check.
also where is the authoritative source ā¦ e.g. perhaps the one on the forum is newer compared to repo.
this is NOT an issue of using a repo , its an issue whenever you create more than one place to share.
(and (a) makes the forum the natural primary source)
this was the reason I suggested a link back to the forumā¦ to try to head this off (a bit)
on the flip side, git (or similar) is useful to grab everything at onceā¦
so for sure, those that know/use git (or other repos) are going to always find it more attractive, but the issue is how to resolve the above issues.
mirroring (as we are discussing here), is of course, a solution but indeed requires manual maintenance - and whilst, I can see some doing it for a while - Im sure most will get bored of it pretty quickly.
e.g. how many are going to want to start uploading instrument definitions that they donāt useā¦ due to (see a above) the original author not being familiar with git?
Id say the viability of this is down to how many ātech headsā we have here sharing definitions, if its a high percentage, I can see it working wellā¦ but if its low, itāll not work so well.
(and Ive no idea how the community is slewed in this regard)
I think the only ādangerā would be a split in the community,
e.g. encouraging users to commit to git, but it not placing on the forum.
that I think would be counter-productive for most end-users, as itāll lead to confusion of there to look/share and end up with everyone having to check two different places 
p.s. a small observation.
I donāt think most people need/want to download ALL definitions, even someone with a comprehensive studio - only needs āsomeā of the definitions. (small percentage?)
I think one major benefit of a file store/repo , is the instrument definitions can be organised
however, if this is really necessary (e.g. large number of definitions) this could possibly be done on this forum, e.g. using tags (manufacturer?) and or sub categories e.g. hapax definitions ā elektron
Thank you for your detailed opinions.
Because of organization and version control, using a git repository is my preference, so I will do this.
Others may prefer the forum, each has the freedom to choose. I hesitate to ask Squarp to take on additional burden such as repository centralization and control: they are already doing so much hard work in making great devices!
I enjoy the use of validation scripts, and software testing in general, but others who do not do not need to employ these practices.
Your concerns about a community using multiple platforms could be readily alleviated by smart use of the hyperlink. For instance, a hyperlink from this forum to repository hosted on github, so that forum users can find such content.
In any case, I hope Squarp will clarify a permissive license for the instrument definition file- it seems their intent is to allow users to edit and share these files, however the applicable statement from the website is:
Any representation and/or reproduction and/or partial or total use of all or part of the Website or its elements, by any means whatsoever without prior written permission of Squarp Instruments is strictly prohibited.
As such, I will not yet share my validation script, as it is a derivative work of the Squarp instrument definition file. Other users will make their own decisions about removing publicly-available instrument definition files; my interpretation of Squarpās disclaimer is not intended as legal advice.
2 Likes
With all due respect, weāre not talking about Dropbox here.
As an example, a clear killer feature of a git would be the ability to fork a repository to add your flavour (say the [ASSIGN] block) while being able to stay up to date with the original repository for general updates.
ā
With that said, I think it is important that there is only one source of truth for instrument definitions and that it has a low threshold for contributing (which rules out git).
2 Likes
We considered going the repo route, but figured the barrier of entry is indeed too high.
Wrt licensing, we intended all instruments definitions files on the website to be freely distributed and modified, without any hassle. Iāll clarify this on the website, maybe refer to the CC0 licence.
.
.
Hehehe, āBank Select (MSB)ā licence 
5 Likes
sound good, CC0 seems appropriate.
perhaps you could add to this topic , and make it non-hidden.
probably worth doing the same for the pyramid def category for the same purpose.
some other ideas for how we could improve things a little
allow definition files to be uploaded
(add .txt to allowed extensions in discourse)
this would enable users to upload the actually definition file rather than cut nā pasting it into a post.
itād also be easier for others to use, by just downloading the file, rather than also having to cut nā paste.
as a nice side effect, a script could also then easily pull the definitions from the forum automatically,
if one wanted a flat file layout, or to store in a repo.
tidy up naming of topics
rename topics to manufacturer : model
this would help any automated script ambitions
add manufacture/model to definition keyboards (optional)
have a couple of (optional) keywords in the definition file itself, for manufacture/modelā¦
I see this useful in two possible cases
a) automated script that pulls the definitions, could inspect contents and use to organise into a directory 1structure (by manufacturer)
b) possibly in the future, hapax hardware could use it to āsortā things.
this could allow Squarp to ship some community definitions, and allow users to select via a hierarchy.
(similar to (a) really)
I see we have a small window of opportunity hereā¦
there are only 10-12 definitions on the forum at the moment, so it be quick to go thru by hand and update to the above.
soā¦ create a .txt file, add manufacture/model to it, rename topic title
if we do this now, then I feel that its likely others would copy/follow suit in the future.
4 Likes