The way I see it, a real PG-1000 doesn't set it's faders to full off, or full on, so any rough starting point would be an advantage...
I've only used a real one once, it belongs to a friend who is a big D-50 fan, he got it from the USA, and bought a D-550 with it. He actually only wanted the PG-1000, but the guy wouldn't split them.
I didn't know if an edit buffer could be created so that the patches information was accessible to the VPG could refer to it.
The JV-80/90's had a temporary area that you could change patch data / performance data. Once happy, you then stored the information to an internal memory location.
Hey, what do I know, I don't want you to go into melt down. It was purely a what if moment..
Yeah I got my PG-1000 from the US too and got stung by customs here too :(. I mainly got it so I could work on my VPG-1000 version.
Yes the PG-1000 and my version do store the patch data in memory when you request it, otherwise it's just sending the positions of the sliders as you move them for the particular partials/commons that you have selected.
What I'll do is look at implementing this for sliders which at a particular point in time are representing one value. As the other cases aren't really feasible to display
E.g. If for a particular slider, you have partials U1, U2, L1 and L2 selected and their values are currently 12, 27, 73 and 29 respectively the slider can't represent them all at once but if I just select U2 then the slider could jump to 27 to represent the single selected partial - if that all makes sense (If you think this is fun, you should see the logic for display "previous" and "monitor" values - that was meltdown time!!!)
I've just had another look at this thread and realised you've now set up a dedicated site, it's looking good.
I've just downloaded v10, but i've been working abroad all this time, so i still haven't had a chance to try it out. I have however installed the software and it looks great. Judging by the other posts, it seems to be working as it should now, so i look forward to finally trying it out.
Just one idea. Would it be possible for you to create a "random patch" function where the D50 (or the editor??) just creates a random set of parameters and sends that to the D50? Most of the time these are pretty useless sounds, but now and again a good one pops up. Obviously this is something that wasn't on the original synth, so not sure how easy it would be for you to create it??
Ahh yes I remember you mentioned that you were gonna be away - and yes it's gone through a few changes.
Someone else mentioned the idea of randomising the patches which in it's simpliest form is incrediably easy to do but as highlighted, you sometimes only want certain bits of the patch to be tweaked and maybe by only so much. So I have been pondering ideas for coming up with an user interface for specifying the sections to randomise and by how much - trouble is there are lots of parameters that they user might have to configure. So it still needs some thought but watch this space.
One feature I'm working on right now is the ability to map control changes to patch parameters i.e. so that you can also change parameters in the program using real-time controls on a synth which actually will work in the real-time editor too.
Anyway hope you find it works ok - and keep the ideas coming
First of all thanks a lot for providing this great tool! I got a d50 recently and I am so happy there is a program available which helps to archive and sort out the many user patches available on the web.
I downloaded a total of over 10000 patches as sysex dumps and imported them in no time into the library of your program. Enabling the "eliminating duplicate patches" while importing reduced the library to around 4000 patches.
While wading through the library I had a few ideas for features which you might want to consider if you have a chance for further development:
- A keyboard shortcut to send the selected patch to the d50. Or maybe an option to automatically send the patch as soon as it is selected in the library.
- enable cut/paste operation (CTRL C / CTRL V) on the text strings entered in the "Comments" column
- After deleting a patch from the library the library view jumps to the beginning of the list. It would be more convenient if the patches surrounding the deleted patch were still visible in the window.
- The possibility to eliminate duplicate patches while importing to the library is a great feature! Browsing through my library of downloaded patches I realise however that there are still many sounds around which are almost or completely identical to each other. It would be a great help if there was a feature to automatically group similar sounds together. This should be possible by analysing the patch data. I imagine it could be quite difficult to define the rules by which similarity between patches can be detected. (On some parameters a change by one step can completely change the sound, i.e. STRUCTURE or PCM WAVE NUMBER whereas others are more "continous" in nature i.e. envelope levels and times)
Two different ideas come to my mind regarding how the user interface for this could be realised (a OR b):
a. Let the user select a patch and then sort the patches in the library in a way that the most similar patches are on top of the list.
b. Add an additional option to the "Filtering" section of the library window: If the option is enabled only patches which are similar to the selected patch are displayed.
Anyway, the program is a great help just the way it is right now!
Thanks for the feedback - always very useful to have it.
I think the first two should hopefully be straight forward (although sometimes you are at the mercy of the controls that are used in the app!!). Certainly with first one there is the "Send One Patch" click button at the left hand edge of the row which sends it in one go but I'm sure a configurable keyboard shortcut could be implemented. The third one was mainly as it's quicker just to refresh but I'll have a look into it as well.
It might be possible to implement the "similar patches" model but as you said, each parameter has to be weighted by how much of an effect it has on the sound. I'll have a think about this one.
regarding the "similar patches" filter:
I noticed that many of the similar patches floating around differ only by very few parameters like for example the "reverb type" and "reverb balance". If you could implement a simple algorithm that detects a patch when say 95% of the parameters are identical (just coounting how many parameters are the same) this might be very helpful already. Of course the patch and partial names should not be taken in account as these obviously have no impact on the sound. Also the "total volume" of a patch does not alter the sound itself.
I have had a think about some of the suggestions so here goes:
- I have added a keyboard short cut of F12 for sending the currently selected patch to the D-50 (from Sysex Window, Library and Real-time Editor). I picked this key as it doesn't interfere with any other keyboard combinations which are likely to be used for editing etc.
- Copy and Pasting works with Ctrl+C and Ctrl+V respectively but the particular cell must be in edit mode (e.g. where you can type) otherwise it conflicts with the Copy and Pasting of patches and I don't want to start changing the way you copy and paste patches based on which column the selected cell is.
- Deleting a patch won't do as much of an update as it did so it's a slight improvement. I didn't want to have to totally re-engineer this bit (because of updating counts and page numbers, links etc) so it will work better as long as the items you are deleting are in the visible part of the grid (otherwise it gets very messy to try and work out which should be the new top row and which should be the new selected row, particularly if you have multiple items selected all over the place - one of those supposedly simple things which always turns out to be messy!!)
- I have had a few more thoughts about the idea of patch comparison. What makes it tricky is that it can be down to personal interpretation as to what is considered similar - so more feedback required on my ideas. Here is the basic concept:
Each parameter has a state indicating how it affects a similarity check:
1) Ignore e.g. names, patch total volume
2) Minor e.g. Envelope times, Pulse Width
3) Major e.g. Structure and Waveforms
If it's set to "Ignore" it doesn't affect the comparison. If it's set to "Major" then any parameters which aren't the same are not similar. If it's "Minor" then it's only considered similar if within a certain threshold.
How the threshold works is where I'm having trouble.
Here are a couple of ideas:
The threshold is a percentage and for each parameter the difference is calculated as a percentage of the overal parameter range. This is because a difference of 1 in a parameter like Envelope Level isn't much when the range is 101 (e.g. Min = 0, Max = 100) but for something which only has a range of 0 to 4 (e.g. "Key follow (time)"), a difference of 1 is quite a bit.
So the threshold is then used to trap any patch where if any of the parameters are over the threshold the whole patch is considered different, but if all of the parameters are different but each one is within the threshold, it's considered similar.
The same percentage threshold is used as above but it applies to the average difference of all parameters. So if one parameter is completely different (e.g. one parameter is 0 and the other is 100) then the overal difference is a lot lower.
I'm leaning towards idea 2 but want to see what people think before I implement it. I ideally want the solution to be based on generic rules as above - I don't want to have to put specific rules in for certain parameters. And with the above ideas I can make it so the rules are stored in the library so people can tweak the comparison state of each parameter as well as the threshold.
Of course there is always the one you suggested of just counting the parameters too - that would be even easier.
Sorry for the long post but these things always get complicated when you start to think about them technically!!
Thanks for considering my feedback for your development!
I think it is a very good idea to let the user define which parameters are important to be included into the comparison. I also believe that idea 2 is more promising. As an extension to this averaging method you could let the user assign a weight factor 0 to 100 for each parameter instead of the three categories ignore/minor/major.
As an alternative to comparing the calculated overall difference to a threshold you could also offer to sort the patches based on the calculated value. (Most similar patches on top of the list)
Another idea that comes to my mind is that there are a number of specific situations where a change of certain parameters does not affect the sound.
- If the filter cutoff is low enough the resulting signal is a sine wave independently of the original waveform (square or saw)
- In structure 1 and 6: if all the parameters are swapped between two partials of the same volume no difference will be heard
- partial parameters have no impact on the sound if the level is 0
- changinging structure from 1 to 2 if the second partial has level 0 will not be heard (same applies for structures 3,4 and 6,7)
As I mentioned in my previous message, many "similar patches" were created by changing very few parameters, so even if the above mentioned special situations are not taken into account the filter function will be very helpful.
Thanks again for the input. I have used your idea of a 0-100 weighting for each parameter to experiment with 3 different approaches now but am still not sure they are quite right yet. Although I appreciate the idea of handling specific situations, I really want a more simple data driven approach i.e. not analysing the parameters based on their exact meanings and interactions - therefore preferring the idea of a weighting to indicate the importance of parameters so that simple number crunching can be applied.
For the 3 algorithms I'm working with the user would set a minimum %score threshold which each patch must get in order to qualify as a similar match. Note: in all of these when I say "All Parameters" I mean all except the Name based ones
1) Parameter Matching
At least X percent of parameters must match exactly (where X is the %score threshold). I haven't used any parameter weighting at the moment but I'm wondering if the weighting should be used to determine whether a parameter is an exact match (e.g. if the weighting is 100 then the parameter must match exactly - but if the weighting is 50 then the parameters can be out by 50% of the parameter range to count as a match)
2) Average Difference
The difference between all parameters is averaged (as described in earlier posts above). The weighting per parameter is used to reduce the difference for that parameter therefore reducing the overall difference and making a closer match
If for one parameter whose range of values is 0-99, and if one patch's parameter is 30 and the other patch's parameter is 50 then:
I have found that this algorithm can give very high scores to patches where there appear to be lots of differences because out of the 117 or so parameters, if 100 match exactly then of the 17 that aren't the same, they can differ a lot but still result in an overall high score because the 100 that match bring the average right down. I was wondering whether the average difference should only be based on parameters that are different (or maybe that might make things as equally bad!!!)
3) Difference Cutoff
All individual parameters must have at least an X percent match (where X is %Score). Again the weighting per parameter is used to reduce the difference for that parameter. So in this algorithm you only have to have one parameter whose percentage match is less than the overall threshold and the entire patch won't be returned.
As an example of parameter weighting values, 100 might be given to things like Common.Structure and Partial.PCMWaveNumber which are important, around 50 to Envelope levels and times which are semi-important, and 0 to Patch.TotalVolume which is unimportant. So the more important the parameter to the patch, the higher the weighting.
I needed to get some sleep first and then take some time to read carefully through your last post as we are getting to the gritty details by now
You observed that the 100 identical parameters in your example bring the average down. I don't think this is a problem, one just needs to adjust the threshold low enough accordingly. You need to make sure however that you don't truncate the calculated "similarity score" of the patches to whole numbers as the differences needed for the judgement might be visible only behind the decimal point. (I hope I managed to express this thought clearly - We are moving to mathematical territory here. I am not used to express such stuff in english..)
You wrote: "I was wondering whether the average difference should only be based on parameters that are different (or maybe that might make things as equally bad!!!)"
I think that would result in a patch having a difference of say 50% in one single parameter being judged as equally similar to the reference patch as an another patch having the exact same difference of 50% in several parameters. This would make no sense.
To me method 2 seems to be easy enough to understand for the user and the one with the most flexibility.
Your last paragraph on parameter weighting is straight forward and understandable to me. It would be a good idea to define a default set of weights so that newby users can start using the feature just by adjusting the threshold an not needing to understand the details of the algorithm.
I know the feeling - sometimes this "math" stuff can fry your mind
Yeap, I have taken the decimal point bit into consideration and only rounded it at the very last minute(as do you really want to know that a patch is a 75.28 match vs 75!). It made a hell of a difference if it was rounded up too early.
I have applied some default weightings for each parameter. Everything is set to 50 with the exception of Patch volume and MIDI related settings are set to 0 (as they aren't important), and Structure, WaveForm and PCMWaveNumber are set to 100. Let me know if you think others should be tweaked.
I have had another thought. With things like PCM Wave Number, the difference in the 2 parameters values actually shouldn't really matter, it's the fact that they are different that's important as the numeric values have no bearing on how different they will sound. E.g If one patch is set to "Upright Bass" (30) and the other "Clarinet" (31) then the difference only comes out as 1 where as in another case one might be "Marimba" (1) and the other "Loop24" (100) where the difference is then 99 - but in actual fact both sounds would probably be equally different sounding. So maybe based on this, there might have to be a configuration for certainly parameters which basically states that if they are different then the maximum difference is applied.
I agree with your thought on the PCM wave number. Applying the max. difference if unequal seems to be the right approach to me. A different wave number will only make a different sound if the wave is actually audible, i.e. if the partial level and tone level are higher than zero. (This is actually also the case for all other partial / tone parameters)
I just realized that you already released an update featuring the F12 key as a send button in the library view. That's great, thanks!
Did you have any chance for further thinking on the "similar patches filter"?