DSI Patch Editor... please Dave.

[hugo]

I know this subject was already discussed around the web many times.
Last night i've watch Dave's interview recently published by the The Nashville Electronic Music & Synthesizer Group, besides other interesting thinks, Dave said he listen to the costumers requests, i believe so.
Being a owner of a P12K and a OB6 soon, it's quite hard to believe that such amazing instruments could rely on third part software to users can get the most of his synths.
I strongly believe that a Patch Editor designed by DSI will make lot of users extremely grateful.

[Robot Heart]

I can say with much certainty this will not happen for any of our existing instruments. Dave is simply not interested in developing and supporting software editors in addition to hardware synthesizers. It would make our company larger at the very least, and we are an intentionally very lean and agile operation.

I realize editors are convenient for many reasons. But, Dave designs synths so everything accessible from the front panel, which deems software editors unnecessary even if they are useful. However, he is open to any third-party software developer making editors for our instruments. So, if someone wants to design and sell an editor they can have 100% of the proceeds.

I know that's not the answer you wanted to hear, but that's the reality of the situation and Dave's been extremely firm on his stance for many years now.

[chysn]

It doesn't necessarily follow that DSI-produced editors would be any better than third-party editors. And there's a long tradition of third-party editors for synths.

Software development is a ton of work. Not just designing and testing, but also maintaining for every new OS. And the support, oy vey, the support. If you don't think it'll be fun, not doing it is the best plan.

But please, make it easier for those who want to do it. The early DSI instruments were a breeze to work with, because the SysEx documentation was really good. I've written my own software for Mopho and Evolver, and I felt like I could find everything I needed. Recent instruments, maybe a different story. I've read about folks trying to find the SysEx format for the Tempest, other guys resorting to grueling dump-and-compare techniques because the bulk dump parameter order isn't documented for some instruments. Maybe consider that aspect just a bit more as you prepare manuals. Front panels are great, but there are lots of legitimate reasons to want to use SysEx too.

[dslsynth]

But please, make it easier for those who want to do it. [...] Recent instruments, maybe a different story.

True! I have been complaining about this for ages now and nothing have really happened until I asked directly and was offered some of the internal C enum types and lists used in their own code.

For the record I am working on a tool that parses these data structures and generates HTML and LaTeX documents. Obviously one gotta supply extra information such as renaming of parameter names and attaching value definitions. But its doable and working as of writing.

What is missing is me writing documentation for this tool and asking DSI for more information as I do not have the complete data available yet. Aspects like multiple versions of some of the newer sysex formats have been completely undocumented until Razmo asked about it on the other forum. So there is a documentation backlog to be resolved.

One way to solve this would be for DSI to pack up these types/list files for each version of each instrument and providing them to anyone who is interested. Optionally these files could be made available for download on their homepage. Then I could publish my tool here - which is currently a Unix shell script - and the community could make the detailed sysex documents as a collaboration project.

In this way DSI would not spend too much time on documenting their formats and users would have the complete documentation available.

Of cause it would be nicer if DSI just had published the complete information up front. But we all know that is not how things work currently.

[Fuseball]

The one person that does appear to get this Sysex documentation upfront and in advance of everyone else is Sound Tower. This gives Sound Tower preferential status, effectively making them the officially endorsed supplier of editors.

I don't have a problem with this, per se, but I wish DSI would exert a little pressure on Sound Tower to better reflect the parameters and functionality of their instruments. The P-6 editor is full of lazy bugs that they don't seem bothered about fixing.

http://forum.davesmithinstruments.com/index.php/topic,325.0.html

[hugo]

I can say with much certainty this will not happen for any of our existing instruments. Dave is simply not interested in developing and supporting software editors in addition to hardware synthesizers. It would make our company larger at the very least, and we are an intentionally very lean and agile operation.

I realize editors are convenient for many reasons. But, Dave designs synths so everything accessible from the front panel, which deems software editors unnecessary even if they are useful. However, he is open to any third-party software developer making editors for our instruments. So, if someone wants to design and sell an editor they can have 100% of the proceeds.

I know that's not the answer you wanted to hear, but that's the reality of the situation and Dave's been extremely firm on his stance for many years now.

I totally agree with most of your points, in my case i use my synths for music and sound design, i also think the general approach of DSI regarding the UI and menu diving is quite well achieved, but in some cases, mostly when i work in sound design, i feel the necessity of a reliable patch editor where i can follow the signal path more easily, mess up with multiple modulation parameters and see the result in front of my eyes.
Machines like Evolver, P08 and P12 are the cases where i think it's more obvious since are complex instruments.
Sound Tower is not doing a god job, i truly respect their work but they are not even close to follow all the DSI OS updates and implement new functions at time.

I hope a collaboration or a kickstart project could occur and join a few talented software programming people that use DSI could lead us to an alternative we don't have nowadays.

[Razmo]

Well... that DSI (Dave) do not want to create editors I can live with... but then for god sake, fix your MIDI bugs when people report them! ... The Evolvers still suffer a lot of these, and the Tempest still has no fix for SysEx bugs on the DIN ports.

If DSI did their own editors, I bet these bugs would be found while designing the editors, because I'm certain they would not allow for a commercial editor to be released, with things not working.

If they fix all bugs reported to them, I have no qualms about them not doing editors... mostly because I can make my own. Only problem I still have is the same as others have mentioned: The SysEx structure is being let out these days... i had to analyze a dump for every f****** single parameter to figure out where it was in the dump... if you want people to create editors for you, then please give them the FULL specs please.

And then... that Tempest SysEx spec... please do not make more of these packed format, bit-compiled SysEx structures... it makes it VERY difficult to create editors...

And a final note about the use of editors... I have to disagree completely with Dave's philosophy that it's not needed because everything is on the front panel... no it is NOT! ... there are menus to dive, knobs and buttons have more than one function on many of DSI's synths, and it IS easier and much more intuitive, as a sound designer, to have an editor to work with... knobs, though fast to edit, also have a tendency to be hard to make fine adjustments with sometimes, making an editor a god sent.... and then maybe the most important reason in my own case: I have so many synths I work with at the same time, that having all of them in front of me is simply impossible... we are still a lot of "studio rats" out here with more than one synth, and without the eagerness to go on tours to only be a "performance guy"... For me it's important that I can remotely control all those modules I've got, from my computer, all at the same time, not having to walk back and forth between different devices all the time...

Now I cannot decide what Dave is supposed to think about this, and the choice is of course his, but one thing I do have control over is what I want to buy in the future, and one thing is certain... if MIDI specs is not up to date, and well documented, I have no choice but to stop buying DSI products...

[dslsynth]

The one person that does appear to get this Sysex documentation upfront and in advance of everyone else is Sound Tower.

Well others have been given access to this information too for some of their instruments. What I means with my above post is that it would make sense to make better sysex manuals as a collaboration between DSI and the user community. But of cause that requires DSI to be willing to publish the information and more forum members than just me being willing to participate in the process. A more systematic approach to sharing of precise sysex information would certainly be an improvement.

Now I cannot decide what Dave is supposed to think about this, and the choice is of course his, but one thing I do have control over is what I want to buy in the future, and one thing is certain... if MIDI specs is not up to date, and well documented, I have no choice but to stop buying DSI products...

You see that is what I am working on that tool I mentioned above: trying to make it easier to make precise sysex documentation in the hope that it will the standard moving forward once the process is in place. Having access to the types and lists from the OS sources means that the documentation always will have the correct program vector index and controller values which is a major improvement over the more recent manuals. Assigning value ranges to the parameters is still a manual process but its easy to make changes as one is specifying a recipe for value assignments rather than editing table entries manually.

[Hector Space]

I totally agree: Proper documentation for sysex dumps (when unpacked) should be provided. It doesn't need to be in a PDF. It could easily be driven directly into a text file from the headers that DSI must have and placed in a suitable controlled access folder on this site, complete with version info. This isn't a big overhead. Really! It is just doing your house keeping DSI.

I've had experience of SoundTower elsewhere. I can say that Mark's position is a difficult one. This is because he faces the same set of problems. Software development can be a minefield even when you are dealing with members of a team in one company. Once you add third parties with or without direct contracts it becomes an act of faith. Clearly if Mark's data interface spec (how much of this is down to DSI not having a clear set of info for SoundTower?) is wrong or the DSI interface software has been changed or is buggy, his editors aren't going to work. On top of which SoundTower are supporting multiple OS versions on multiple platforms. All of which change without any warning.

Anyone else trying to do their own editor librarian will quickly realise it's a nightmare, involving a huge investment of time and effort and never ending bugs. Without committed support from the synthesiser developer it will never work. I'm sure part of the problem is the success DSI are having! Growing pains are synonymous with buggy and poorly documented software.

My view is that the editors should become open source projects. Casio's PX5s editor is like this and it works quite well. This would require a commitment to openness from DSI and a ton of effort from us lot. 😜🤓🤔