Nytt projekt blir utmaning för 99mac

Men det vore bra att veta om man "får" använda iPods till exempel, MD är ju ett lite gammalt och riktigt struligt format pga. allt kopieringsskydd.

kan bara instämma med dom som nämnde att itunes databasen nog inte skulle klara det. Har ingen pratiskt erfarenhet utav detta, men jag vet att apple förmodligen inte har haft fleranvändar performance i tankerna och så är itunesdatabasen xml baserad.

Dock så finns det gott ommöjligheter att i perl, php, mf och säkert .Net med (om man nu skulle vilja det) parsa ID3 taggar. En riktig RDBMS såsom PostgreSQL eller MySQL skulle palla trycket mycket bättre, och som nån nämde; vara mera öppet mot framtida förändringar.

Kanske man kan tänka sig att man rippar skivorna lokalt på en av klienterna i studion, att göra det automagiskt ger jag inte mycket för med dagens teknologi, när detta är gjort läggs dom i en "hotfolder" på servern (antingen manuelt eller man kör ett applescript när man är klar). Dessa processas då och info ifrån mp3 taggarna (som man noga övervakar när man gör dom) extraheras automagiskt och lagras i databasen.

Nu när man har det i databasen, så kan man genom sitt (icke-publika) webbbaserade gränssnitt browsa runt i katalogen, skriva recensioner för skivor/låtar och lyssna på dom direkt genom webbläsaren (varför göra det krångligt att köra dom tillbaka i itunes på nått vänster bara för att lyssna på en låt).
Dels kommer det nu gå mycket bättre än i iTunes (om vi nu snackar ett antal klienter), dels fler möjligheter för metainfo för varje låt/skiva och statestik.

Man kan kanske även tänka sig att man gör egna "playlists" i detta gränssnittet, när man sen har en ~60 minuter utav musik så kan man välja att spara ner detta till en stor fil i en särskild folder eller så på servern, som man sen på passande sätt överför till minidisc, eller hir distrobutionen nu skall ske ifrån den centrala musikstudion.

Så skulle mitt förslag gå rent spontat efter att snabbt ha läst igenom denna diskussion, jag tror (tills jag har hört ett bättre förslag ) att det är det som skulle vara mest lättanvändligt för användaren. Jag har inte gått in i detaljer för ljudformat osv eftersom min kunskap ärligtalat är begränsad där..

Den frågan är redan besvarad tidigare i tråden. Nej, MD ska det vara. Men om en tränare har en egen iPod att koppla in anläggningen i träningslokalen så kan det inte vara något problem. MD är det som ingår i anläggningen i träningslokalerna.

Tränarna kommer till studion och väljer låtar och mixar ett antal. Det ska sedan ner på MD.

Om jag har fattat rätt så är de inte intresserade av att ändra sina mixnings-rutiner. Det enda de är ute efter är ett enkelt och smidigt sätt att leta reda på låtar med diverse nödvändig information.

Det största problemet som jag ser det är att det blir många konverteringssteg.

Jag tror att ett enkelt sätt är att använda sig utav iTunes för lagringen och konverteringen till AAC samt för informationen (BPM, etc)
Jag gjorde ett snabbt test med ett delat iTunes bibliotek på en server och det fungerade alldeles utmärkt så länge man inte blandar olika versioner utav iTunes.

Sedan kanske man skulle kunna utnyttja XML exporteringen för att uppdatera ett FileMaker register om man vill ha en "audio offline"-planerings databas.

Men som sagt, det stora problemet är alla konverteringssteg.

Först måste man konvertera hela biblioteket till AAC, med nödvändig info och betygssättning. När man sedan har valt ut låtar så kopierar man de till "studio"-datorn och, beroende på mixprogram, konvertera till AIFF för redigering.
Har man ipods är ju överföringen lätt som en plätt om man använders sig utav iTunes. Däremot så måste man använda något annat program ifall man använder sig utav MD.

Eftersom det inte står skrivet någonstans att de har planer på att byta rutiner för mixningen så utgår jag ifrån att de sitter i ProTools, Logic eller Cubase där en konvertering till AIFF krävs. Dessutom så vet jag av erfarenhet att det är otroligt svårt att få en inbiten studiotekniker att byta sequencer/mix-program över en natt.....

Dessutom bör AAC till AIFF konverteringen vara relativt smärtfri bara man får rutin på tillvägagångssättet.

Jag tror att iTunes ändå är ett starkt kort i och med att det går att dela musikbibliotek via nätverk samt att den har relativt bra editeringsmöjligheter i ID3-taggen.

En lösning med iTunes i centrum och ett centraliserat "Bibliotek" på en server är nog inte helt dumt.......Så kan man komplettera med kringprogram om det behövs.....

Jag vet inte om det är ett så stort problem. Det borde gå att använda Folder Actions. När filerna kopieras så hamnar de i en mapp som kör ett Apple Script och QT kan väl göra konverteringen åt mappen.

Jo, när jag tänkte efter och provade lite så insåg jag att det inte bör bli något problem.

Jag fattade det som att de satt med cd-spelare och mixer och mixade analogt idag.

Kan detta vara något.. Finns en del godbitar på denna sida: StudioEase
/L

Det där med mixer verkar ha blivit en för stor fråga just nu.
Som jag skrev så jobbar vi inte med någon form av mixning idag. Vi spelar in spår i följd, pitchar gör vi på CD-spelaren och fejdandet sköter vi på MD-spelaren. Återigen: En förstärkare, en cd-spelare och en MD-spelare - det är allt som finns på varje inspelningsplats idag.

Vet inte om det förändrar saken att vi just nu INTE avser att ha mixmöjligheter. Får vi det 'på köpet' - visst! Men lösningen måste vara EXTREMT användarvänlig.
Och vad det gäller digitaliseringen av de befintliga skivorna så är ju det en, om än slitsam, engångsgrej. Sedan är det ju bara nyinköpen som skall in och de pulsas redan idag manuellt av oss som ganska grundligt recenserar plattorna.

Anders

Ok, vad sägs om ett förslag som bygger bara på iTunes? Väldigt användarvänligt (som de flesta av iAppsen) men kommer kräva en del av "Admin".

* Använd iTunes på klientdatorerna men kopplade till serverns musikbibliotek.

* Använd "Comments" fältet i iTunes ID-taggar för nyckelord/recension eller motsvarande.

*Gör Comments- och BPM-fälten sökbara via AppleScript.

*Gör extremt många "Playlists"! Dessa kan ju vara kategoriserade hur som helst, allt från "Bra startmusik" till "Endast armhävningar" via "Får de flesta att gråta om de försöker hänga med" och "Gubbar och tanter över 70 pass". Samma låt kan ju vara med på olika playlists.

*Med hjälp av Comments, BPM och Playlists så borde "vem som helst" kunna hitta låtar, även i ett stort bibliotek.

*Använd AppleScript för att exportera valda låtar till vald folder/enhet. (Jag vet inte hur MD fungerar på Mac, dyker den upp som en extern disk? Om ja, så kan scriptet spara låtarna deirekt på MD:n...)

*Ingen mixning/fadning men den sker på MD ändå?

Klart!

Som jag förstod det så var det överföringen från dator (AAC eller mp3) till MD som var problemet. Att det kan ske med optisk kabel verkar ju rimligt - men formatet...hmmm

Anders

Anders,

Du skriver:

lösningen måste vara EXTREMT användarvänlig

Ponera att användaren som ska skapa en låtlista:

1. Går in på en intern webbsida.... (Inloggning krävs förståss...)
2. Söker efter låtar enl. valda kriterier...
3. Markerar de låtar han/hon vill ha med... (Valfri låt kan förhanslyssnas..)
4. Organiserar dem i korrekt ordning...
5. Döper "sin" spellista...

Nu skapar systemet en fil med just de låtar som valts, i rätt ordning...

6. Användaren går in i "sin" mapp på en server...
7. ...för att sedan kopiera/spela över den till MD.

Låter detta som en EXTREMT användarvänlig lösning!?

-Torkel

Nu börjar det likna något

Allvarligt talat så är det ju nåt sådant som jag sett framför mig. Men går det att man pitchar upp låtarna i burken INNAN man lägger över det på MDn?

Anders
(kravmaskin )

Anders, har ni någon priliminär budget? Personer här inne har ju börjat spekulera iPods, G5:or och Xserv... Hmm vore bra att veta om vi inte sitter och spårar ur, Budgetmässigt...

Det diskuteras databaslösning kontra enbart iTunes. Hur långa är de recensioner som skrivs? Görs de av hela skivor eller av hela låtar? Att använda kommentarer i iTunes skiter sig om man vill ha mer än 256 tecken eller något liknande. (Jag räknade hur många tecken det accepterade och kom till 260-någonting, men 256 låter väl rimligare - jag kan ha räknat fel.)

CD->AAC->ATRAC blir aldrig bra!

Kör man ett komprimerande (ljudförstörande) format och sedan konverterar till ett annat dito låter det skräp. Det blir betydligt enklare att hålla takten till musiken om kvalitén är hög. Titta hur det ser ut på ett dansgolv nästa gång ni går på disco, folk dansar ej i takt. Det beror på det sunkiga ljudet på i princip alla discotek, bastakten är otydlig. Lyssna på Pointer Sisters "I'm so exited" så förstår ni vad jag menar, det ska vara dunk---dunk, dunk---dunk---dunk, dunk. I mindre goda anläggningar låter dubbeltrampet på baskaggen som ett enda utdraget dunk.

Konvertering mellan olika komprimerande format suger fett enl min åsikt. Gör lite olika tester och jämför med originalet på CD, ni kommer att bli förvånade. Om databasen med lagrad musik ska vara i AAC el MP3 så välj då minst 192kbps. Det är först vid 320kbps som det blir svårt att skilja från cd-originalet.

Läs mer om jämförande test mellan olika format och ljudkvalitén på iPod:
http://members.brabant.chello.nl/%7em.heijligers/ipod/

Varför fortsätta krångla med MD när det inte funkar nåt bra med Mac, man kan bara föra över musik i realtid. Bränn ett träningspass på CD istället, snabbare och bättre kvalitet. Antigen i originalformat el MP3 om era spelare klarar det.

Edit: Nu är det rätt låttitel

haha, så jag försökte säga också, fast förklarat mycket krångligare

jag tror att det vore det bästa, och enklaste för användare. Dels kan dom lyssna på enstaka låtar direkt i webbläsaren, dels har man mycket bättre möjligheter för meta info; alltså mer än bara ratings/antal spelningar etc. och därmed mycket bättre sökmöjligheter!

iTunes ger jag inte mycket för i det här fallet. Jag tror det kommer behövas en riktig databas.

Och jag med...

NetJuke har ca 90% av den funktionalitet som ni/jag beskriver. Kostar desutom gratis

Nja att folk inte alltid dansar i takt på discot beror nog mer på folks "kreativa" danser och alkoholens inverkan. Plus det faktum att ljud färdas runt 300 meter per sekund och har man då ett stort dansgolv så hör inte alla beatet exakt samtidigt.
Detta kan man dock korrigera rätt billigt med digitala delayer och nogranna mätningar men då får man lite andra nackdelar istället.

Den gamla LINN sloganen att man automatiskt stampar takten till musiken endast om man har en bra anläggning har alltid varit ett lamt försök att sälja visserligen bra men grymt överprissatta hifi delar.

Att folks gympglädje skulle påverkas märkbart av kompressions effekter tyder ju inte direkt de utomhus jympningar som jag har sett och hört där ljudet inte direkt har varit lysande men glädjen nästan ofattbart hög. Man kommer rätt långt med entusiastiska deltagare och bra ledare.
Missförstå mig rätt jag gillar också välljud , men när hundratals personer hoppar pustar och skriker så kommer nog ljudkvaliten i andra hand.

Enkelt förslag
Varför inte köpa typ 20 st. 40GB ipods och fylla dom med de bästa låtarna från arkivet och skicka runt dom regelbundet i landet så ledarna själva kan få styra spellistorna och kopiera över sina favoriter till MD eller CDR med lite hjälp från recensioner på deras website.
iPod roundtrip typ.

Avancerat förslag
Eller så kan man ju låta någon/några "klippa" och bpm:a upp alla önskade låtar i 4/8takter i typ Abelton LIVE eller Apple's soundtrack program och därigenom spara sjuhelsikes med plats på hårddisken eftersom de flesta maskinella danslåtar ändå innehåller rena repetitioner av mängder av takter.Sedan sätts takterna ihop och adderas när man mixar, skulle också göra det lätt att mixa även äldre låtar eftersom bpm avvikelser kan justeras om det nu är önskvärt.Dessutom så kan man enkelt höja/sänka tempot på låtarna utan Kalle Anka eller Bosse Bas effekter.

Dessutom kan man förlänga intron och breaks väldigt lätt om man "klipper" upp låtarna. Något som gymledare brukar uppskatta.
Grymmast är nog ändå om varje ledare hade en iBook 60gb med Abelton Live
(liknande Soundtrack fast ännu mer lättanvänt)
Runt 25.000 lååånga (valbart) låtar skulle nog få plats i varje iBook utan kvalitetsförlust p.g.a uppklippningen. .
Då skulle dessutom nya låtar loopar och mixar kunna laddas ned trådlöst. Plus att iBooken säkert skulle kunna utnyttjas till lite andra uppgifter också.

Jag pallar tyvärr inte läsa allas inlägg in denna debatt så det finns en risk att detta program redan är nämnt. I alla fall:

Jag hade helt klartsatsat på en webbaserad lösning som spottar ut en färdig mix. För att få in och administrera mySQL databasen hade jag använt DOMO ( http://domo.sourceforge.net ) under linux (går säkert att kompilera för MacOS X också eftersom det bara kör QT och lite småbibliotek) Detta hanterar import från CDDB databas, MusicBrainz identifiering och mycket mer och för in allt i en prydlig databas.

Webplatsen hade jag skapat via Zope, Plone med språket Python som bas. Vid mixningen finns det flera småprogram som kan ändra tempot utan att ändra pitch vilket jag tycker är att föredra.

Nej nu skall jag sova så jag nöjer mig med detta förslag just nu.

Vi som har utvecklat en del lösningar åt F&S Riks (tex en PrintOnDemand-lösning för skapande av trycksaker som tex visitkort och flersidiga broschyrer med beställning av tryck av desamma) skulle kunna bygga en sådan här sak.

Eftersom vi jobbar mycket i FileMaker Pro och Applescript så skulle vi kunna skapa en lösning med allt som finns i specifikationen baserad på detta som i sin tur pratar med iTunes.

Bygga upp arkivet
iTunes kodar filerna och bygger upp arkivet och hämtar data om skivorna från CDDB (drivs av Gracenote.com), filerna placeras även på servern vid samma tillfälle. Inloggad användare är en admin, den enda som har tillgång till hela filarkivet. Tillgång till filerna styrs sedan via FileMaker Pro som "loggar in" på servern med olika användare och kopierar filerna ner till lokal hårddisk (kanske onödigt, men jag ser det som en säkerhetsgrej att inte ge alla användare tillgång till hela arkivet och alla låtar som finns där med skrivrättigheter)

* Ett Applescript körs som skapar ett antal poster i FileMaker Pro (en per låt i en databas och en per CD i en annan databas).

* Ett Applescript fortsätter med att kopiera CDDB-informationen från iTunes till motsvarande poster i FileMaker.

* Scriptet avslutar med att lägga in MP3-filerna i ett sk containerfält i FileMaker (kan därmed spelas upp direkt i FileMaker)

Efter allt detta så finns ett gäng filer (i formatet AAC, AIFF, MP3 eller WAV-filer beroende på inställningarna i iTunes) på servern och sökvägarna till dessa är inlagda i FileMaker Pro

Komplettera informatione
* Musikgruppen loggar in i FileMaker Pro-systemet och kompletterar informationen som finns om låtarna i filarkivet. Här bygger vi en finfin sökmotor som kan visa nya filer eller bläddra bland CD-skivor eller göra valfria sökningar.

Ledarna bygger playlists
* De startar FileMaker Pro och använder det för att söka fram och bygga upp ett större eget arkiv med en massa filer i. De kan provlyssna direkt i FileMaker Pro men de använder inte FileMaker för att bygga playlists. De "plockar ut" låtar ur FileMaker och lägger dem i sin egen "låthög" så att säga. När de är klara så klickar de på en knapp...

* ...som kopierar låtarna i deras arkiv till datorn de sitter på. Sedan körs ett nytt Applescript som säger åt iTunes att lägga till de låtarna i iTunes arkiv. (Annan inloggning än admin = andra inställningar i iTunes)

* Nu kan de leka med att bygga playlists för olika typer av pass och sedan kopiera filerna till sin Minidisk. (Lite osäker här om man pluggar in sin MD i ljudutgången och trycker på play i iTunes eller om man kopierar filer till den som en USB-disk.)

* Om man vill kan man sedan köra ett annat Applescript som flyttar över den nya playlisten in i FileMaker Pro igen. (Gör man det kan man sedan underlätta avrapportering för ledarna då de i ett webbgränssnitt ser sina playlists och där kan de med några mycket enkla hangrepp ange hur många gånger och när de har spelat en viss playlist. Från det kan man generera statistik till STIM. En sådan avrapporteringsfunktion kan vara webbaserad då det är en helt separata databaser och inte ger någon tillgång till musik-filerna)

Fördelar med denna lösning
Troligen tokbillig att bygga jämfört med en massa annat kångel (som krångel betraktar jag MySQL-databaser, Perlscript, webbaserade lösningar med PHP, UNIX-kommandon, mix-program, visual basic eller c++-applikationer).

Ger ett superenkelt användargränssnitt också som går att bygga vidare på då man utnyttjar varje program för vad det är bäst på: FileMaker för att agera databas och göra sökningar och bygga ett mycket trevligt användargränssnitt och skjuta ut rapporter, iTunes för att koda filer och skapa playlists och Applescript för att knyta ihop flera separat applikationer och få dem att jobba tätt tillsammans. Vill man kan man välja ut ett program att göra mixar med och sedan låta användaren skapa mixar från de filer som ligger i den lokala mappen (kanske Applescript kan hjälpa till här med?).

Att komplettera denna lösning med en massa annat godis för att lösa administrativa uppgifter som tex avrapportering till STIM, maila ändringar i arkivet till en admin, skapa "centrala" playlists som flera användare ser (kan vara bra hjälp för nya ledare att kunna se en rekommenderad playlist för tex ett spinningpass), göra batchkonverteringar av filer från ett filformat till ett annat eller skapa "intro-loopar" av filer med endast de 20 första sekunderna går också lätt. Det finns mycket kul man kan lägga till om man tycker att det är värt det...

Ungefärligt pris
* Vi talar om åtta databaser (cds, songs, users, users_songs, playlists, playlists_songs, settings, stats) där olika användare ser och kan göra olika saker. Mellan tummen och pekfingret tar detta ca två dagar att bygga. (2 dagar)

* Vi talar om fem Applescripts (skapa poster för CD's och sånger, hämta CD-info ur iTunes och överföra den till FileMaker, montera filen i containerfält, importera alla låter i viss mapp till iTunes, överföra playlists från iTunes till FileMaker). Mellan tummen och pekfingret tar detta ca fyra dagar att bygga. (4 dagar)

* Vi talar om en server där filerna lagras. Säg en Beg G4 (hellre ny G5 eller XServ, men det finns ingen anledning egentligen) med mycket mycket hårddisk. En extern FW-hårddisk på 120 Gb ger plats för ca 2400 CD-skivor om jag kalkylerar rätt med att en CD-skiva är ca 50Mb som MP3. En till för backup. Sedan är det bara att köpa två till externa FW-diskar då arkivet växer. En FireSmart ALU 120 Gb kostar 1590:-.

* På servern behöver vi ett backupprogram (Retrospect Workgroup 4595:-) och FileMaker Pro Server (13.076:-) och Mac OS X Server (4144:- för 10 klienter, 8290:- för obegränsat antal klienter). Att installera detta och konfigurera olika användare tar ca en dag. (1 dag) (21.815:- för programmen)

* Klienterna kan vara någon begagnad iMac eller G4 som kan köra OS X 10.3 (1128:-) med iTunes och Applescript och FileMaker Pro 6 (4080:-/klient) med Troi File Plugin (531:-). Att få en klient att fungera tar en förmiddag. (1/2 dag) (5739:- för programmen)

* Lite strultid, diskussioner, användartester, kravspec och annat, mellan två till fyra dagar till. (2-4 dagar).

Total projektid: 9.5-11.5 dagar (57.000:- -- 69.000:-)
Total kostnad för programvara för tre klienter: 3 x 5739:- = 17217:- + 21815:- = 39032:-
Total kostnad för en ny G5 som server: G5 1.25 GHz = 14.995:- + 2 stycken FireSmart ALU 120 Gb = 3180:-. Totalt 18.175:-
Total kostnad nya iMac G4 1Ghz 15" combo, 3 stycken = 10395 * 3 = 31.185:-

Totalt projektvärde: 145.392:- -- 157.392:-

Lättast att spara på är förstås server och klienter och vad jag vet så finns det redan FileMaker Pro server och FileMaker Pro klienter i organisationen. Att välja hyfsat nya begagnade maskiner minskar ner på priset betydligt.

Man kan förstås tänka sig att lägga upp detta på någon form av leasing eller liknande (inkl lösning) och då betala ett par tusenlappar per månad för hela klabbet under tre år eller så.

Man kan också tänka sig att tre datorer + fet server går att använda för annat i organisationen, att placera flera lösningar och databaser för att underlätta administrativa uppgifter och minska kostnader borde inte vara svårt.

Om något av detta är av intresse, maila mig direkt Ola@intelligentmammals.se eller ring 0709-66 01 99.

/Ola Andersson
Intelligent Mammals AB
http://www.intelligentmammals.se/

Kan tillägga att vi byggt en snarlik lösning med alla delar i enligt ovan för lagring+konvertering av digitala bilder i ett webbserat bildarkiv. I den lösningen sitter Applescript mellan Graphic Converter och FileMaker Pro och hämtar/lämnar information mellan dessa. Lösningen skalar om och flyttar bilder och läser av bildinformation och lägger in det + bild i FileMaker Pro.

I en flera andra lösningar vi har byggt jobbar vi med Troi File Plugin för att via FileMaker Pro flytta och hantera filer och även "skjuta ut" filer i form av färdiga HTML-sidor eller InDesign-dokument.

Vi har också byggt en hel mängd databas-baserade webbplatser med Lasso.

/Ola

En liten kort fråga:

Vad skall du med MacOS X server till? Ser inte någonstans att du använder dig av dess unika funktioner.

Där du ser krångel i MySQL, Perl m.m. ser jag stabilitet, skalbarhet och öppna standarder vilket jag lite saknar i ditt system. Det känns lite sårbart.

Mac OS X Server är endast till för att agera filserver och i mina ögon är det lite lättare att sätta upp en fleranvändarmiljö i OS X. Men du har rätt det är inte nödvändigt. Man kan klara sig med Mac OS X och kanske något i stil med programmet Sharepoints (eller vad det nu heter).

När det gäller MySQL och Perl så har du en utvecklingskostnad med de två verktygen som är 8-10 gånger högre för motsvarande med FileMaker Pro.

FileMaker är stabilt och möjligt att skala ganska mycket (långt långt mer än det här projektet med dessa förutsättningar kräver), så genom att välja rätt verktyg får du en mycket mycket billigare lösning.

Inuti FileMaker finns för övrigt stöd för ganska många tekniker som betraktas som öppna standarder.

/Ola

hmmm........

Din syftning här är lite konstig. För dig med stora FileMaker kunskaper men kanske begränsade SQL/Perl kunskaper kanske utvecklingen tar 8-10 ggr så sång tid. Detta anser jag inte är fallet om man anlitar ett företag med stora SQL kunskaper och färdigskriven kodstruktur. Många delar av detta projekt är ingalunda unika för detta projekt så de kan kan skrivas om så att de passar.

Därför behöver inte kostnaden bli högre om man bara hittar rätt företag.

Samma sak gäller i den branch tom jag arbetar (content management frameworks) många skulle påstå att en php eller lasso lösning är det billigaste att utveckla men har man bara en välskriven stomme så är en Python-zope-sql lösning överlägsen där när det gäller låga utvecklingskostnader.

/Tomas

Ledsen men det är inte korrekt.

Kan förtydliga min klumpiga meningsbyggnad också. SQL-databaser har en utvecklingskostnad som är högre än FileMaker Pro. I ett exempel som jag har hört så låg anbuden för en databasbaserad lösning för att lagra recept (!) från en FileMaker-utvecklare på ca 12.5% av anbudet från SQL-utvecklarna. Därifrån kommer min siffra på åtta gånger.

När man skall bygga en applikation med ett trevligt användargränssnitt och kanske få till lite funktionalitet där olika användare har olika rättigheter och sedan ett antal utskrifter och andra rapporter, så är det helt kört att bygga en applikation i MySQL eller Perl på samma tid som du bygger en i FileMaker Pro.

Även om man inte börjar från scratch som du föreslår utan bygger om en eller flera lösningar man redan har så har du exakt samma problem. FileMaker är snabbare att bygga i.

Skall man bygga en webbapplikation så vinner FileMaker igen. Att man bara behöver sätta ett kryss i en ruta för och kunna surfa till din nya databasbaserade webbsite slår alla andra lösningar med hästlängder.

Men om man vill ha mer koll på hur webbsiten skall fungera så behöver man koppla ihop FileMaker med en middleware, som tex Lasso. Då är min uppfattning att PHP och Perl inte är lika snabba att bygga i som Lasso, något jag diskuterat förut här på 99Mac. Största anledningen är att koden är kortare i Lasso än i alla andra verktyg.

Sedan kan jag också tillägga attjag kan mycket mer om MySQ, Microosft SQL Server och T-SQL än vad jag vill egentligen vill veta. Så jag har inte bara arbetat med FileMaker Pro i livet, jag har arbetat mycket med båda. De är även utifrån den erfarenheten som jag skriver att utvecklingstiden är mycket längre.

/Ola