I would love to be able to drag and drop MP3s to scaler to detect chords. It’s a time waster to have to convert MP3s to wav files just to drag and drop to scaler. Can we make that happen?
I don’t know, but I suspect the Scaler developers use a third party product to do this. It might be one of those ‘buy or build’ decisions to focus on their core strengths. If so, that means they either have to wait for the product owner to do this, or contemplate a significant DSP project to bring it in house.
However, I too suck MP3’s into Adobe Audition to convert them, so I second your suggestion as and when feasible.
It is worth noting that mp3 coding and decoding software may have some licencing issues.. So being able to detect mp3s may result in an increase to the price of Scaler. Do we want that given that mp3 have a lower quality than wav files?
As a work around I suggest you could try using Audacity to make a bulk conversin of mp3 to wav.
Could you explain what you mean by this as I’m just not following you here. Scaler uses a third party product to do… what?
It is very common for software developers to use routines for specialist functions written by third party developers. This is because either (a) they don’t have those skills internally and/or (b) it makes no economic sense to develop those functions ‘in-house’.
This would be the case with such things (for example) as digital signal processing or mp3 encoding. Many are available as ‘open source’; they might be free or attract a one off, periodic or per user licence.
So the Scaler folk when (for example) rendering sounds from samples or doing audio detection would weight up the cost and time of development to do it themselves (“build” ) vs the Net Present Value of licensing (“buy”) and decide on a cost / time assessment which to do.
My guess (and it is a total guess with no evidence whatsoever) is that the sample rendering in Scaler is home brewed and the audio detection is third party.
There is another related situation because (as in the case of the mp3 format) the format or process might be patented; mp3 was patented until 2012, so if you wanted to write code to produce an mp3 file you needed to pay a licence to the owner.
I imagine Scaler corporately as being conceptually musicians with technical skills to hand rather than an IT company with musical skills, so if it’s cheaper to use a tried and tested and possibly free function you would do so, and - amen to that - Scaler costs less that it otherwise might.
Yes, I am fully familiar with the mp3 licensing as its translation was always regulated and quite well known, much like jpeg in the photoshop world. The audio detection I always got the impression was developed by the Scaler team since Ed spoke about it with a bit of pride as it compared to others doing similar detection. In any event it’s all speculation on your part as you said.
There was another thread I pinged you on about the exporting of chord sets under the USER menu and if you had done a study on it as you often do. So if you have any expertise on it the thread is here Saving and Recalling User Chord sets - How?
I’m asking out of curiosity because I’ve never tried it myself. How well does Scaler recognize chords from an Audio file? If I take a song from YouTube and turn it into a wave and open it in Scaler Audio?
It will detect chords and put them in section A. Scaler does not detect timing information so it won’t recreate the song just the chords in the order detected. You can then copy them to the patterns section C and use them as you like.
I effectively ignored the provided mechanisms to save chord sets etc and decided to focus entirely on the export state function instead (which I still do) .
Sadly, however, I went down a long and tedious rabbit hole which terminated in a dead end. The theory was that, since the state export saved everything, I could interpret that and store it in a structured database. On doing the export, the system was intended to detect that automatically, analyse the file and store it, having prompted me to enter a brief description / category first. I could then query this with any parameter (the plan went) and restore the state file for import when required.
As you know, the state file is full of weird mumbo jumbo (UUIDs) which I managed to decode after a lot of effort, and put together a system to read a state file and analyse it e.g.
I then worked on building the chords from the midi notes
and bunging it all into a database.
My problem is I never know when to stop. So the next bit was to work out what other scales/modes fitted a chord and then on common tones between all the scales… I tested all this out in a beta spreadsheet I dropped on the board.
However, I realised the one thing I was NOT doing was making any music, so I stopped this insane (but stimulating) side track, and switched my focus to try and create 12 pieces, using only Scaler, Omnisphere, DUNE and BBC SO.
So (in brief) I’ve not really explored the chord set set issues, but am more familiar now the with the guts of the state save, of which the others are actually a subset.
PS To give you a flavour of my nutty plans , I experimented with programmatically amending state files - I won’t bore you with the reasons now - and it does work So Here is the root of a Cmaj scale
So exporting state, if one alters the second note to 51 instead of 52
and then re-import the state, the chord changes to Cmin
Here, I’ve only altered the chord, but you get the general gist is that you could programmatically produce a whole sequence of Scaler files without having to tap stuff into the GUI.
Madness, and I needed to get back to making something melodic.