Hi,I am on 2.0.0.svn25 (Build 3002). Regardless which tool I am using, I cannot add instruments to the database.I have created the DB and I see it being created.Whenever a ADD DB_INSTRUMENTS .... is issued I get an OK, however, I cannot see the newly created instrument.I have tried directories, files, SFZ, SF2, GIG all to no avail.Any clues?Regards,Robert

Where <db_dir> is the absolute path name of a directory (encapsulated intoapostrophes) in the instruments database in which only the new instruments (that are not already in the database) will be added, <file_path> is the absolute path name of a file or directory in the file system (encapsulated into apostrophes). In case an instrument file is supplied, only the instruments in the specified file will be added to the instruments database. If the optional <instr_index> (the index of the instrument within the given file) is supplied too, then only the specified instrument will be added. In case a directory is supplied, the instruments in that directory will be added. The OPTIONAL <mode> argument is only applied when a directory is provided as <file_path> and specifies how the scanning will be done and has exactly the following possibilities:

"RECURSIVE" - All instruments will be processed, including those in the subdirectories, and the respective subdirectory tree structure will be recreated in the instruments database

"NON_RECURSIVE" - Only the instruments in the specified directory will be added, the instruments in the subdirectories will not be processed.

"FLAT" - All instruments will be processed, including those in the subdirectories, but the respective subdirectory structure will not be recreated in the instruments database. All instruments will be added directlyin the specified database directory.

If FILE_AS_DIR argument is supplied, all instruments in an instrument file will be added to a separate directory in the instruments database, which name will be the nameof the instrument file with the file extension stripped off.

The difference between regular and NON_MODAL versions of the command is that the regular command returns when the scanning is finished while NON_MODAL version returns immediately and a background process is launched. The GET DB_INSTRUMENTS_JOB INFO command can be used to monitor the scanning progress.

Possible Answers:

"OK" - on success when NON_MODAL is not supplied

"OK[<job-id>]" - on success when NON_MODALis supplied, where <job-id> is a numerical ID used to obtain status information about the job progress. See GET DB_INSTRUMENTS_JOB INFO

Where <db_dir> is the absolute path name of a directory (encapsulated intoapostrophes) in the instruments database in which only the new instruments (that are not already in the database) will be added, <file_path> is the absolute path name of a file or directory in the file system (encapsulated into apostrophes). In case an instrument file is supplied, only the instruments in the specified file will be added to the instruments database. If the optional <instr_index> (the index of the instrument within the given file) is supplied too, then only the specified instrument will be added. In case a directory is supplied, the instruments in that directory will be added. The OPTIONAL <mode> argument is only applied when a directory is provided as <file_path> and specifies how the scanning will be done and has exactly the following possibilities:

"RECURSIVE" - All instruments will be processed, including those in the subdirectories, and the respective subdirectory tree structure will be recreated in the instruments database

"NON_RECURSIVE" - Only the instruments in the specified directory will be added, the instruments in the subdirectories will not be processed.

"FLAT" - All instruments will be processed, including those in the subdirectories, but the respective subdirectory structure will not be recreated in the instruments database. All instruments will be added directlyin the specified database directory.

If FILE_AS_DIR argument is supplied, all instruments in an instrument file will be added to a separate directory in the instruments database, which name will be the nameof the instrument file with the file extension stripped off.

The difference between regular and NON_MODAL versions of the command is that the regular command returns when the scanning is finished while NON_MODAL version returns immediately and a background process is launched. The GET DB_INSTRUMENTS_JOB INFO command can be used to monitor the scanning progress.

Possible Answers:

"OK" - on success when NON_MODAL is not supplied

"OK[<job-id>]" - on success when NON_MODALis supplied, where <job-id> is a numerical ID used to obtain status information about the job progress. See GET DB_INSTRUMENTS_JOB INFO

Where <dir> should be replaced by the absolute path name of the directory. If RECURSIVE is specified, the absolute path names of all instruments, including those located in subdirectories ofthe specified directory, will be returned.

Possible Answers:

A comma separated list of all instruments (encapsulated into apostrophes) in the specified directory.

"ERR:<error-code>:<error-message>" - if the given directory does not exist.

.'LSCPServer::AnswerClient(ReturnMessage='SHD:1:LIST DB_INSTRUMENTSThe front-end can retrieve the current list of instruments in specific directory by sending the following command:

LIST DB_INSTRUMENTS [RECURSIVE] <dir>

Where <dir> should be replaced by the absolute path name of the directory. If RECURSIVE is specified, the absolute path names of all instruments, including those located in subdirectories ofthe specified directory, will be returned.

Possible Answers:

A comma separated list of all instruments (encapsulated into apostrophes) in the specified directory.

"ERR:<error-code>:<error-message>" - if the given directory does not exist.

The instruments DB feature maintenance is orphaned for quite a while now. Grigor used to work on it, so it hasn't seen an update in several years now.

Looking at your debug output though, I see what the problem is: you are adding sound font files, and when the current instruments DB feature saw its last (major) updates, support for SF2 and SFZ by LinuxSampler did not even exist yet!

So right now the current instruments DB implementation just looks for .gig files when scanning for instruments. When I find some time, I can look for adding the missing code for SF2 and SFZ files. In the meantime, in case you want to help adding support for this, have a look at src/db/InstrumentDB.cpp. At line 1153 (method AddInstrumentsFromFile()) it checks the file name extension (i.e. ".gig"), and method AddGigInstruments() adds the respective .gig file to the DB. So the missing code for SF2 and SFZ must be added there. If you need some help on this, just let me know. You may also consider to subscribe on the linuxsampler-devel mailing list in that case, since the LinuxSampler developers are not reading the forums every day.

thanks for the answer. I guess I will not subscribe to the mailing list. I am really, really old, but mailing-lists are still older Isn't there any other way to communicate with the devs?

I have gdb'ed adding a GIG file but still, I have trouble when I add the "Philharmonia Trumpet long loud" from Open Orchestra, which remains in my folder '/home/rschneid/Documents/Music/soundfonts/linuxsampler/philharmonia_trumpet_long_loud.gig', this is what I get in the DB:

I have gone one step further and as I said in my previous post, the Strings for path, name, artist etc. are correctly passed into BindTextParam, however they are corrupted in the database.I would assume, the strings are somehow on the heap which is cleared up before the sql-engine writes the data to the database file.

I wanted to file a bug, but I do not have a bugzilla account and I cannot create one as Account Creation is disabled and I do not know how to read Andreas Persson.

And one more finding. The memory corruption doesn't seem to be create only, it also seems to occur on reads to the DB.I have manually filled the DB with entries and at some, I can get a GET DB_INSTRUMENT INFO and on some I can't. There is nothing in the records that would explain that.BindTextParam seems to have severe issue.

robertaramar wrote:thanks for the answer. I guess I will not subscribe to the mailing list. I am really, really old, but mailing-lists are still older Isn't there any other way to communicate with the devs?

You mean like a LinuxSampler WhatsApp group? No, the only reliable and fastest way to discuss developer issues is the linuxsampler-devel maling list. It is simply the least common denominator, because not everybody uses Google+, FB, etc. , but everybody got an email address. I would agree with you if it was an 80s style newsgroup (where you had to use special clients etc.), but in case of mailing lists I don't really see a disadvantage.

robertaramar wrote:I don't know whether this is the proper fix, but it cures my problem:

That fix is correct. SQLITE_TRANSIENT causes the supplied Text to be copied immediately, which was not the case with SQLITE_STATIC, and hence this was a severe bug causing undefined behavior of libsqlite, since "Text" is just a temporary variable.

I am not used to the instruments DB code, but there may still be further bugs like this one. For example sqlite3_prepare() should probably be replaced by sqlite3_prepare_v3(). The SQLite docs are not clear on that, but it could be that the old sqlite3_prepare() function is not copying the original SQL statement text, which then might also cause undefined behavior due to the same cause as above.