That’s what we did. Often without any response.
We mentioned:
- the fail of the editor as PlugIn under Apple / Logic.
The editor still don’t work as it should be. Working with the hardware is correct, but there is no data exchange with Logic - neither you can’t record movements in the editor nor recorded controller data is displayed in the editor.
( http://forum.moogmusic.com/viewtopic.php?p=151176#p151176 )
- the lack of functionality in the librarian (both standalone and plugin)
you cannot swap presets in the hardware list when the destination is not visible, because the list won’t scroll with a picked up preset. This is just needed to sort your presets but without it, it makes the librarian useless.
It’ even not possible to copy and paste.
- The unsorted library
The hardware bank (right pane) is sorted in order of the preset numbers.
Why you don’t use the same concept in the whole library (left pane)?
When I copy presets to the library, my order (bank/nr) is lost. So I can never save one bank as it is as a “backup”.
- parameter values:
regarding bob moogs intention “to built always instruments for musicians”, the parameters values displayed in the editor are really a shame.
What should I do with a cutoff value 81564??? You printed reasonable values on the surface of the hardware. Why no use in the editor too?
You’re able to scale parameters like keyb track (LFOs) in percent, or show the real waveforms, so why not with every parameter?
- sending SysEx data from the sub37 with every program change
This we described in http://forum.moogmusic.com/viewtopic.php?p=150326#p150326 in detail. Even with the firmware 1.1.16 this is still not solved. So two Sub37 connected together will cause a disaster on the slave device. There was even no answer from Amos.
Gil, we really like to help and spend time to test beta.
But it is often disappointing for us to see there is only little response and things mentioned a while back aren’t solved in actual updates. There are even no comments on some issues from your side. Frustrating.
You really have to differentiate bugs and feature requests. Feature requests are really important and come up constantly. You need to understand though that not every feature request suggested is something which gets into the version, or at least not into the upcoming one.
I also believe you are answered (and have been answered) about each report you’ve made, and as I said before, we do our best to read all reports and feedback every day (many times on weekends as well). Our main goal is being able to process all data into bug reports and feature requests, but as with any product, not all of them are ending up treated. We do prioritization of all items based on time limitations and the current status of the beta all the time, so there definitely are going to be some suggestions or bugs which won’t get fixed or embedded in the upcoming version - it still doesn’t mean these reports are being ignored, so please understand that.
Also, please note that the improvement suggestions, feature requests etc. are mainly treated by Amos, which is the product manager of the Sub 37 and Editor. It may take a while until every note made on the forum gets it’s response as we are mostly actually working on the product/s and monitor this forum from time to time. I hope it makes sense to you.
you’re right, the most postings I did you have answerd. But these issues we talked about, like the plugin in Logic, the library faults or that one Sub destroys (resp. overwrite) another Sub presets are purely functional issues and not feature requests.
Of course, and they are all valuable and well documented, and go into the same path as all other bugs and feature requests (prioritization). Some issues are just being investigated by the development team, are currently in development or just set to a future version. Sorry if it makes you feel they are being ignored, but this is definitely not the case !
Hi guys! Thanks for all your time and effort, and my apology for not keeping up the conversation from my end.
I missed this report entirely until now. It’s easy to confirm. I’ve flagged it as a serious thing to fix before release. It’s really quite necessary for any serious re-arrangement of presets within the hardware.
This one is already on our list and we’ve discussed internally what would be needed in order to implement sorting in original/arbitrary order. I think it was a big enough change that we didn’t implement right away at the time we discussed it, because we thought we were closer to release (at that time). We can take another serious look at this, as it is really a nuisance not to be able to drag a bank of presets to a user folder and keep them in their original order.
Friendly parameter values… I was resistant to making this change right away, due to the amount of work involved to collect the unique mapping from raw value to friendly units which is different for every parameter. (well, different for each of quite a few types of parameter)… but many musicians are asking for this; everybody who’s expressed an opinion has agreed that real units is the right way to do it. So, this will surely come. But we are so far behind schedule to release, that I can’t insist that this improvement must be completed prior to v1.0 release. I’ll see about beginning the necessary background work to help this feature along.
I am almost certain I typed some kind of reply to this, either on this forum or by email, around when I was coming home from NAMM.
Working on a fix now, so that the Sub37 will only send out sysex on the port which is connected to the Editor, and not the other port (i.e. no sysex out the DIN MIDI, if editor is connected via USB, and vice versa). For now at least, the Editor relies on sysex sent per preset in order to keep the editor in sync. Separately, I have a proposal for a method where the editor “syncs itself” once per session, by requesting from the hardware any presets which were modified & saved there, since the last time the editor was connected. Then the editor and hardware can communicate using only CC/NRPN and program change, during normal operation, and not send preset sysex on every preset change.
Kind regards, and again I apologise for the times when it seems like there is slow or no response. We are always working behind the scenes, and trying not to overlook anything! I, especially, sometimes need extra help and reminding.
Thank you very much, Amos and Gil too. I do appreciate your answer.
Btw, perhaps you can expand my account on the forum to the beta tester forum too. So I don’t need to use LuLoops account furthermore (much thanks for that, LuLoop).
Looking forward to a great release 1.0
cheers,
Bernard
Of course! There’s been a bit of confusion, as until now a third person (neither Gil nor myself) was required, to let people into the beta tester forum. Now, Gil can do this.
Your user name is simply “bernard”, correct? Please confirm and we’ll make sure you are added to the beta forum permission list.
Tonight we played with the test software, you send us.
This is the usual situation: Editor connected via USB and the second Sub37 is connected via MIDI (of course, two Subs can’t be connected via USB).
But the firmware does it quite reversed:
MIDI Out sends program change AND SysEx data, so the (slave) Sub37 preset still will be overwritten.
USB sends ONLY program change. That has the additional effect that the editors knobs, buttons etc. don’t react to the preset change made with the Sub37.
I see two possible solutions, I like to discuss
The Sub37 sends by default NO SysEx together with the program change.
Then, If the editor receives a program change, it requests the SysEx dump via the port the Sub is connected to the computer, either MIDI or USB.
So, a connected second Sub via MIDI will usually see never the SysEx.
In addition, the MIDI bus will be relieved.
The other way could be, sending SysEx always on both ports like up to now, but a preset in the receiving Sub will not be overwritten, instead, the data could be dropped to the buffer only. One has to save it to keep it eventually. Btw, the usually way on synths, I know.
The disadvantage is that there are many data on the MIDI bus, which could be to slow when playing back recorded notes with program changes together.
This is really strange, and not at all what was intended, nor what I’ve observed. I’m definitely seeing my Sub37 replying sysex over USB, when the editor is connected via USB. I will double check to be certain that it’s not also sending sysex via DIN at this time. It really shouldn’t be.
In firmware v1.1.19 / v1.1.20, the Sub37 really does not send out any sysex on program change. Make sure ECHO DIN IN and ECHO USB IN are turned off, on the Sub 37 that is connected to the Editor.. to be sure the editor is not outputting sysex to both connected Sub 37s somehow.
This is also possible, to have hardware sysex output always to be the “buffer sound” version… but in theory, the other fixes should alread relieve congestion of the MIDI bus (less sysex being sent overall) and there should be no preset sysex output from the hardware except in response to a direct request from the editor (get all presets, or capture HW buttons).
Make sure you’re using the latest v1.1.20 firmware, and meanwhile I’ll check it again over here. Some of your suggestions should be implemented already, according to what I know about the recent firmware…
Thanks Amos for reading.
I installed the v1.1.20 firmware and no SysEx is send over MIDI anymore. So far so great.
In a couple of days, I will check the functionality between the two Subs again.
