ljud databas prg?

Wxwidgets verkar sjysst, ska jag kolla upp närmare oavsett.

Har inte funderat på databas så mycket. De enda jag använt i jobbet är MS SQL och MySQL och det är ju inte som några lämpliga kandidater. Så det blir väl lite efterforskningar.

Ska hursomhelst utvärdera in-memory databaser för jobbet, som ska lira på både Windows och Linux, så det ger sej. Tips mottages iofs tacksamt.

SQLite finns tror jag? Men det är nog filbaserat och inte in-memory.

Som sagt.. skissa gärna ner mer exakt vad för funktionalitet ni är ute efter till applikationen.. så kan man spåna på vad som är lämpligt sen. In-memory eller inte.. helt orelevant fråga just nu tycker jag.

> Det är endast microsoft själva som enligt lag får utveckla en fullständig version
> för en annan plattform.

Det där var en intressant sak. Jag trodde det stod vem som helst fritt att implementra rubbet om man ville/orkade/kunde. Det gör ju tex Mono mer eller mindre dödsdömt eller åtminstone handikappar det svårt. Var hittar jag mer info om det där?

Ang val av plattform så det som talar för Java enligt min mening är väl att man kan få allt med i ett, integrerat å så. Jag menar, logik, GUI, databasmotor osv. Man behöver mao inte 'krångla' med andra libs som QT/wxWidgets + någon enkel databas. Jag tänker mig att det är enklare att få upp en sådan fungerande miljö så man kan koncentrera sig på själv implentationen istf att få en massa oberoende paket att funka ihop. Eller är jag för optimistisk i min tankegång?

In-memorybiten var för ett jobbprojekt alltså...

Håller med. Nackdelen är att användarna måste installera en runtime.

Hursom, ska se om jag kan få ihop ett första utkast på spec inom ett par dar, så tar vi det därifrån.

TMB: Förr så fanns det en del info om det där på monoprojektets hemsida. Det handlar om en del patent hit och dit..

I övrigt så nej.. jag tycker inte att det är märkvärt lättare att få upp en fungerande miljö i java än för c++/python/ruby. Edit: Eller snarare.. den lilla uppoffringen i extra "krångel" tycker jag är mer än värd besväret.

ok.

Volle: Får ta och kolla runt lite. Klart intressant för den biten framgår inte riktigt när folk proponerar för dotnet som plattformsoberoende och att man kan använda Mono på andra plattformar.

Tja, vi får se vad Peter skakar fram för något så får man fundera utefter det.

Peter: Jo, det har du ju rätt i men å andra sidan så kan de behöva installera en massa andra paket istället som tex just Qt/wxWidgets osv. Och en java-runtime har väl nästan alla installerat vid det här laget.

Nu var det där iofs riktat mot peter.. men jag svarar ändå: Om användaren blir tvungen att installera sådant själv så har utvecklaren gjort något galet. Så nej.. det ska absolut inte behövas!

Han måste åtminstone installera applikationen

Beror på hur man ser det. Jag brukar inte kalla filkopiering för installation. Så enligt mitt synsätt så.. nä.

Jo, men när programmen in Windows installerar sig så fint och gräver sig in överallt i systemet så är det bortom vanlig filkopiering enligt min mening. Och så måste ju det här programmet också funka. Jag menar man kan ju inte bara ta en exe-fil och lägga någonstans och köra, det... det... det är ju emot hela principen

Tänker på det där programmet man kunde ta hem från M$ som installerade sig bara för att kunna tala om om man hade en Vista-kapabel maskin

Förutsätter att det går att länka statiskt till Wx-dll'er? Om man nu vill det.

Det som känns viktigt är att användaren inte måste hämta saker från en massa andra håll och kanter, en installer man man ju alltid leva med.

Exakt, som Gimp - hämta här och här åsså här Går det att sätta samman i en installer eller paket så är det ju bäst. Hur är det med Qt och wxWidgets? Får man distribuera bara libben om man vill? En del vill ju att man installerar det separat så att allt hänger med.

Det är väl bara till att läsa igenom licenserna. Annars så finns det flera sådana bibliotek.

Ett första utkast på spec. Har ni fler ideér om funktioner, PM'a mej, så jag får med det i orginaldokumentet. Vi kan väl samla in förslag några dar, sen får nån göra en tidsuppskattning. Utifrån det och antalet intresserade utvecklare får vi sen avgöra om det känns värt besväret...

Har skrivit på engelska, utifall vi skulle komma fram till att open source av något slag är vettigast.

Defining categories

Categories is a treestructure. A sound can belong to several categories, on any level in the tree. They are freely defined.

Defining properties

A property is a value between two opposites, for example a precentage between Soft/Hard, or other discrete values, like BPM or pitch. Sounds can have multiple or no properties.

Scanning for files

The user can select what filetypes to scan for, and include/exclude directories. Any type of file is handled, although preview only works for audiodata.

Setting categories/properties

Any new file is added to the unassigned pool, where an efficient GUI lets you assign categories and properties with a minimum of manual labour. A regular expression mask can be used to assign sounds in batch. Several files can be grouped together, comprising one sound (eg multisamples)

Searching

Querys can be constructed using boolean operators and flexible searchvalues. Examples in mock SQL syntax:

(Category = Snare OR Category = Kick) AND Dry/Wet > 70% AND Soft/Hard > 80%

Category = MelodicLoop AND Tempo BETWEEN 120BPM AND 140BPM AND Pitch = A2

Raw sounddata can be audiotioned directly in the searchresult. A "find similar" function takes all properties of a sound into account, and searches for similar files.

Adding to project/copying to projectdir

Files from the searchresult can be added to a current project pool. These files can then be copied to a projectfolder for use in other software

Drumkits

Drumkits can be constructed and auditioned using a simple stepsequencer. A searchcriteria is assigned to each row in the sequencer, and a pattern entered by the user. The sound for each row is then selected from the searchreasult. A random function can also cycle thru each resultset, allowing the user to "freeze" sound for each row, until a full kit is constructed.

Kanske vettigt att starta en ny tråd så man kan få det samlat i förstainlägget?

...det märks att vissa är mer utvecklare än användbarhetsmänniskor.
Inget ont om idéerna i sig, men jag har träffat rätt få människor som begriper sig på regexpar, och av dem är få musiker.

Personligen tror jag på någon av följande varianter:

Taggar. Dvs ljud kan taggas med ett gäng olika benämningar, och sedan uppstår förhoppningsvis ordning ur kaos. Fördelen är att man slipper trassla med att bygga kategorier som sedan ändå inte kommer passa in för ljuden man har. Har man en syntetisk koklocka man vill kategorisera så petar man in "drum", "synthetic" "cowbell", istället för att lägga den möjligen under "synthetic->drums->percussion->cowbell" eller "drums->percussion->synthetic" eller "synthetic->roland->x0x->drums->percussion->sampled" eller möjligen alla 3.

Enkelriktade properties. Det är svårt att hitta självklara motsatspar för många kategorier. Mjukt-hårt, visst. Snabbt-långsamt, visst. Rock-vad???, x0x-vad??? Bättre då med en enkel och uppenbar skala. (De som har uppenbara motsatspar kan dessutom ofta formuleras som "tempo", "volym" eller liknande.)

Metadata. Utnyttja det som går att få ut från ljudet i sig. (Gissat) tempo och tonart, längd, dynamik, etc.

Att jag trycker på enkelhet ovan är inte bara för att de flesta musiker inte är så haj på SQL och reguljära uttryck, utan för att problemet i minst lika hög grad är att klassificera ljuden och inte sökningen i sig.

Det är ingen mening med att ha världens bästa sökmetoder om man inte orkar klassificera alla ljud på ett vettigt sätt. Handen på hjärtat, kommer ni orka sitta och gå igenom tusentals trumljud och klassa dem på en skala mellan hård-mjuk och tre andra skalor? Jag skulle inte göra det.

Jag förstår poängen (att lätt kunna lyssna på ljud i sitt sammanhang), men det tror jag man löser bättre genom att skriva programmet som en plugg eller låter det svara på midi. Ingen mening att skriva en sequencer när det redan finns färdiga och mycket bättre.

klassificering av ljud borde ske automatiskt... att klassificera utifrån ljudfilen kan bli ganska svårt DSP-meck med men det vore ju störtcoolt om programmet var ett virtuellt öra och kände igen snaretrummor osv En uppskattning om tonen på samplingen skulle vara bra tex.

Enklast är väl att först och främst klassa utefter filnamnet, de flesta samplingar tenderar ju till att heta nånting typ BD kick bassdrum hihat1 hihat2 osv... man kanske skulle kunna koppla ihop synonymer vid sökningen oxå så att sökning på tex "bassdrum" även ger träffar på "kick" osv?

sequencern tycker jag låter som ett typiskt "version 2.0 -krav"...

Jag tror du fått med allt faktiskt. Iaf det jag känner att jag vill ha med i ett sådant här program. Du har redan tänkt på det där med en pool där man kan jämföra ljuden och liknande. Sedan så kanske mer önskningar utkristalliserar sig när man börjar använda det.

Tublenco: Image-Lines nya sampler DirectWave gör just det. Kanske inte exakt allt du beskriver, men de är på väg åtminstone. De har en tjänst där man kopplar upp sig via samplern till en databas och söker efter ett ljud man behöver, köper direkt och lägger in i samplern.

Vet inte hur pass perfekt sökningen är just nu, man klickar sig nog fram via kategorier, men den kommer säkerligen förbättras desto fler användare som anger sina behov. Det finns demo att prova på
http://www.image-line.com/documents/directwave.html

Citerar Image-Line

En tanke som jag hade var att databasen skall vara exporterbar, dvs man skall kunna exportera hela eller delar av databasen, tex på sampleskivenivå tex så folk kan byta databaser med varandra vilket gör inte varje enskild person behöver sitta och klassificera samma samplingssamling. Detta kräver dock en rejäl tanke, skall man tvinga filstrukturen? Eller kan man låta databasen söka upp samplingar på filnamn eller kanske tom checksumma på datat i filen? Skall man tillåta customtaggar och hur skall dessa då hanteras, tex användare A gör en ny kategori som heter 'Hårdsynt' och en annan, användare B, kallar samma sak 'Leadljud'. När person B skall importera person A:s datafil för den samplingsskiva som de har gemensamt så har användare B plötsligt en ny kategori som betyder samma sak. Man kanske skall erbjuda mappning eller iaf hopslagning av kategorier i sådana fall.

Hm, blir väldigt avancerat det där...

Jag har iaf förutsatt att enkelriktade properties är en sak som skall vara med. Som du säger, många saker har ingen motsats.

Jag tror detta är oerhört svårt. Det skulle förmodligen ta längre tid att skapa filtren och få dem att fungera för att extrahera den här informationen än det tar att göra det för hand. Fast iofs, står man inför valet att tagga 1000 kickar för hand eller krångla med ett filter så vettephaen

Nu snackar jag bara funktion och inte tillvägagångssätt. Har inte alls tänkt att man ska behöva knappa nåt slags SQL-variant, utan ett snyggt GUI ska det vara. Men det är mycket lättare att beskriva mina tankegångar på det viset, utan att behöva photoshoppa upp ett GUI.

Regexp behöver ju inte vara svårare än *hihat*.wav. Sen finns det oändliga möjligheter för den händige. Har svårt att se hur det skulle lösas annars? Är väl ändå bättre att använda något befintligt och väldokumenterat, än att koka ihop någon egen soppa?

Det var det som var tanken med regexp'en.

Tror ändå det är bättre att ha en hierarki, blir så jäkla svårt att navigera om allt ligger på samma nivå. Ger också en bra känsla för hur precist ljudet är definerat.

BPM och Pitch är ju inte definerade som motsatspar. Visst kan man kalla BPM för Fast/Slow, men det var inte tanken, den är enkelriktad. Dte är ju bara en benämning på en skala, Soft & Hard är ju inte två skilda "objekt", rent databasmässigt, enligt mina tankegångar.
Tror inte det kommer att göra någon som helst skillnad i användning, och iom att användaren själv definerar egenskaperna, så gör var och en så som faller sej naturligt. (Sen kan man ju skicka med några default iofs).

Det var hela tanken.

Är ju inget som hindrar att man slänger in hela låtar, och använder för att skapa DJ-set, eller vad som helst.

Eller synthpatchar, istf för .wav osv.

Absolut. Men det var lite utgångspunkten för hela idén, eftersom jag tycker det är så svårt att bygga trumset som verkligen funkar ihop.

Vi pratar nog om lite olika saker i såna fall.

Jag kallar inte wildcards för regexpar. Men överlag tror jag mer på att hålla det så enkelt som möjligt, för troligen kommer ingen eller väldigt få att använda sig av regexpar i praktiken, och då är det bättre att ha wildcards, bra filter och sorteringsmöjligheter än att försöka skruva in en regexpmotor och skapa ett vettigt gränssnitt för det.

Se till exempel på Google eller GMail. Kraftfulla och användbara sökmöjligheter utan regexpar.

Ett ljud är inte ett träd. Okej, nu handlar den där artikeln om stadsplanering, men jag tror motsvarande gäller för ljud.

Jag tror man får 95% av fördelarna med en hierarki med en lösning utan hierarki + taggar, och undviker dessutom många av nackdelarna när det gäller definitioner, användande osv. Egenskaper hos ljud är mångdimensionella, och det är svårt att fånga i en hierarki.

Jämför tex en hierarkisk databas med en taggad om man ska söka efter tex stråkljud. Har man tex en tudelning i akustika och syntetiska ljud måste man öppna två grenar för att jämföra dem, medan tagglösningen är att bara välja "stråkar". Och att definiera hierarkin enligt principen Typ->Stråkar->Elektroniska/Akustiska leder till att man måste ha den tudelningen i alla ljudkategorier om man ska vara konsekvent.

Om jag tar på mig min filosofhatt ett ögonblick så skulle jag säga att en hierarki tillför semantik där det inte finns någon. Det blir ett ontologiskt beslut om tex ljudtyp (trummor/stråkar/basar osv) är överordnad ljudkällans typ (akustisk/elektronisk) eller tillverkare (lägger jag Rhodes i samma kategori som Stratocaster-samplingar och Jazz-basar, eller hamnar den under pianon? Eller möjligen elektroakustiska instrument? Eller något helt annat?). Dessutom måste användaren komma ihåg sin klassificeringsstruktur både när man lägger till ljud och när man söker.

Det här är inte bara filosofiska invändningar, utan jag stöter på det när jag ska sortera in samplingar i min rätt modesta ljudsamling (strax under 20000 samplingar om jag räknat rätt).

Visst är detta ett problem som går att komma runt med sökningar, men det känns som en krångligare lösning.

Jag tror jag borde slänga ihop en skiss för att visa hur jag tänker mig en taggad lösning. Det blir kanske klarare då.

Hur går det hörrni?

En pytteliten featurerequest.. den får även ta hand om sysex-dumpar!

Semestern tog slut. Och uppslutningen har ju varit minst sagt klen, så jag släppte det...

Det var ju synd. Också lite synd att projektet aldeles för lätt kan kopplas till mitt jobb.. så jag kan inte hjälpa till utan att börja bryta en massa tråkiga regler. Möjligtvis så kanske jag kan göra en sådan gratisapp själv men att företaget står som ägare till koden.. men vette fan om jag inte ska lägga ner den tiden på att vrida ljud då istället
(eller färdigställa min sequencer)

Volle: Var jobbar du egentligen?

Peter H: Synd, jag var iaf på men två stycken kanske inte räcker.

Eftersom jag inte gillar reklam här på forumet så skickar jag ett PM..