Nord User Forum

Hi
You can drag multiple files in one selection (one drag/drop) , but cannot currently make an additional selection (an additional drag/drop).
Ill try to work on this over next few days

I have added the ability to hide (remove) files, and un-hide them.
Its available in the 'patch editor' - just toggle the Hide switch. You can see it working when you view the patch.
There is no need to click the 'update' button when you hide files, you can simply close the pop window.

I think I need to review the data a bit more closely, theres so many incorrect Mp3s when I compare the imported data to the summary on nord_sample_collection.php
not quite sure where this has gone wrong, either on the Excel file that Johanes provided or my SQL import...
It does seem to match Johannes' summaries though, but only 50% of the time nord_stage_2_program_collection.php

Hi Spooky,
I took a look at Johannes summaries and saw that many of my mp3 are wrong and don't match with the mp3s which I uploaded to the patches in my post. In your new database I have added the right mp3s.

I have made some fixes but its never going to 100% correct unfortunately. Can you check your patches again?
there is a chance I reverted your changes. It should be OK but please check..

Thanks for the great job spookycookie!
A couple of observations: would it be possible to visualize more than 10 rows? Many times it's useful to have more patches visible on the same page, so you can easily compare them (when all the mp3s will be available).
Also, would it be possible to add an "advanced search" function? For example, searching only among categories, or only in the patch name, tags, or patches from a certain author, etc.

I also notice that it's difficult to get coherent results doing a text search.
For example, if I type "bass" in the Search field, I get a series of results and among the first I see patches #227 "Dx7 Bogi Bass" and #228 "Dx7 Dirty Bass".
But if I type "Dx7 bass" all I can see is patch #20567 "Nm Dx7 Bass Mw", and I can't retrieve the two patches above.

Hey Spider,
You can set the number rows to 20 at the bottom of the table.
I can certainly improve the search feature, I'll have a think about your example... it would certainly be possible to split the search query into 2 separate queries (Dx7 + bass) but the challenge would be returning the results only when both DX7 + bass are matched.... I guess it might only be a few lines of code, but might take me a few hours to write them . lol

I also had 'column search filters' a while ago on each column which allows for more advanced filtering/seaching at column level, I thought it looked a bit clumsy so I disabled it. If you think it's worthwhile I can turn the column filters back on next time I deploy it

Hey Spider,

I added a button to toggle the column filters off/on. Its top right next to search (which I moved to left side) also added option to set 50 & 100 rows per page - let me know if you want 200, 300 etc... (it starts to slow down a bit)

thanks for the suggestions, I will give some thought to improving the search as per your example

Hahaha thanks, I think 50-100 rows is about where it stops being useful and it starts messing things up.
Thanks for the immediate updates, they're small things but make things much easier!

Here's a geek thought on the search, and this is totally not a request. I'm just geeking out...

Use a separate table which stores terms that can be matched in the search. For instance, when a new sample is uploaded, every word is split apart and added to the search terms table - every word of each tag, every word of each title, description, filename (if it is a long filename, it's just one word, no need to try to do magic on long words).

So each word in the search terms table will not be a unique entry in that table, because it will be a hit for every field that contains that word. Maybe the table schema looks like --
If the table has an index of the term field, any search is fast. Break the search into words, do a single query of the SearchTerms table (The default, case insensitive search has that forced lower case on terms and of course, force the input from the user to lower case. Later, since the table stores terms in their original upper or lower case, a case sensitive search can be done.)

I think MS SQL even has soundex matching and other useful ways to match on things that are a close match. (Here's where filenames would work out, by adding to the query a partial match ability, so a search for ns3p would work like it should.)

Once that query completes, combining results and ranking then is a separate step. So in this example, the search was for "Dx7 bass". Results from the SearchTerms table will include matches on anything with either "dx7" OR "bass"; if one field matches them both, its score is higher.

Or there are good "full text search" systems out there already. Just wanted to geek out for a bit! Cheers!