Helló!

Első lépésnek leírnám hogy mi is az a time code rendszer. A DJ-k használják ezeket. A dolog egy bakelit szimlátor tulajdon képpen.

Úgy működik, hogy felteszel egy-egy spéci bakelitet a lemezjátszókra (működik Cd lejátszóval és spéci CD-vel minden ugyanígy). A lemezen egy meghatározott jel megy mindkét csatornában, amit majd később részletezek. A lemezjátszók rá vannak kötve a hangkártyára. A bejövő jelet a gépen egy szoftver dolgozza fel. A sebességet és a tű pozícióját állapítja meg a bejövő jelekből. A szoftverben pedig bármilyen mp3-at berakhatsz lejátszani. Ezáltal a gépeden betett mp3-akat úgy tudod jétszani, mintha az rajta lenne magán a bakelit lemezen. (A hangkártya kimenetei rá vannak kötve a keverőre.)

Ha pl visszahúzod a lemezt, vagy áthelyezed a tűt, az mp3-ban oda ugrik a lejátszás. Mindezt azért, mert a lemezen levő kódból a szoftver tudja a dolgát.

Az egészben annyi van ami nem tetszik, hogy viszonylag izmos gép és nagy memória kell ezeknek a szoftvereknek. Néhány ilyen szoftver (némelyikhez hangkártya is van direkt) A másik dolog, hogy jó drágák.

-Rane Serato
-Stanton Final Scratch
-Mixvibes DVS
-M-Audio Connectiv Torque

és még gondolom van egy halom...

Egy hasonló rendszert szeretnék megvalósítani, persze jóval egyszerűbben, úgy hogy amit lehet funkciót hardverből megoldani. Nem kell csillivilli mixelő szoftver, mert úgyis ott a keverő. Az elképzelésem az, hogy USB-n a kiválasztott számot átnyomni a hardverbe. Ez még viszonylag könnyen megoldható. Ezután a hardverben a lejátszó megvalósításától függően valami előfeldolgozás. (Pl mp3 dekódolása wav-ba valami nagyobbb RAM-ba, ha mp3-ból egyenesen nem lehet lejátszani)
A lejátszást a lemezről vett jel feldolgozott infói alapján kéne vezérelni. Ez annyit jelent hogy egy sebesség meg egy pozíció infót kell kinyerni.


Ha valakit érdekel még a dolog rajtam kívül, akkor leírom hogy milyen kód van az ilyen lemezeken és szerintem mit meg hogy lehet dekódolni belőle. Illetve a lejátszásról egy kicsit.


Csá

Üdv!

Az mp3-as topikban már említetted a terved, ami nem is lenne annyira rosz ötlet.
Mondjuk szerintem wav-ban érdemes gondolkozni. MP3-nál az a gond, hogy csak kereteket tudsz ugrani és lejátszási sebesség állítása is nehézkes. A másik gond, hogy mp3 dekóderekben lévő puffert fel kell tölteni mielőtt az megszóllalna. A feltöltött puffer tartalmát viszont teljesen lejátsza. Oda akarok kilyukadni, hogy valószínűleg szakadozna a hang a timecode lemez gyors mozgatásánál.
Persze ott a lehetőség egy saját dekóder kifejlesztésének egy DSP-re (ami nekem legalábbis még nagyon távoli dolognak tűnik, bár nem lehetetlen).
WAV-ot kezelni ennél jóval egyszerűbb, és egy 80-100GB-os merevlemezzel a tárolás sem jelenthet problémát.
Szerintem a profi cuccok sem mp3-ban csinálják ezt... illetve tárolni lehet mp3-ban is de a feldolgozáshoz ki kell nyomorítani WAV-ba. Pl. STA0xx DSP I2S kimenetéről konvertálsz WAV-ba egy előre kalkulált mennyiséget (tartalékokkal) és azt játszod le, a timecode-nak megfelelően.

Mindenesetre szép project! Sok sikert hozzá!

Hi!

Nagyon jól látod a helyzetet, azt kell hogy mondjam
A gyári programok is valószinűleg wav-ban kinyomják a memóriába, azért kell nekik többszáz MB RAM. Aztán onnét mehetnek a bájtok egyenesen.

Három megoldási ötletem van.
Az első az STA dekódolós megoldás, itt az a kérdés, hogy milyen gyorsan lehet vele egy mp3-at mondjuk SD kártyára, vagy SDRAM-ba kitömöríteni. Néhány másodperc lenne az optimális, de félek hogy ezzel nem lehet.

A másik az, hogy CD-n wav-ban tárolni a zenéket, audió CD-re úgyis ugyanannyi fér mintha wav-ban van, és CD-ről televágni a memóriát. Csak 50-60MB átvitele gondolom nem túl gyorsan megy. Ehhez PC sem kell, csak két CD olvasó.

A harmadik a vinyós megoldás. Wav ban tárolva. Ehhez sem kell PC, viszont valami FAT16 szerű fájlkezelést meg kell írni hozzá. Az átvitel gyorsasága mondjuk itt is kérdéses, de gondolom gyorsabb, mint CD-ről, még "házi DMA" átvitellel is. Egy kijelzővel ellátva egész komoly vas lenne. A szöveges infók tárolása már részletkérdés a zenékhez.

Szia.

Hardverileg nem lesz egyszerű, de ha mégis szoftveresen valósítod meg akkor lényegesen egyszerűbb lenne.
Meg kell írni egy mp3-wav konvertert (a neten van számos forráskód szabadon) és ebben a wav-ban aztán egy gyengécskébb progi is könnyedén mozog. A hardver pedig egyszerűbb lesz, mert csak az kell, hogy mikor melyik irányba mennyit mozdítottál a lemezen. Ezt a progi feldolgozza és voálá.

Ennyire sajnos nem egyszerű. Az odáig rendben van hogy PC-n wav-ba átírom. Csak azt a lemezt nagyon gyorsan lehet ám cibálni, és ehhez gyors rekació idő kell eléggé. Ha pedig a gépen fut a sebesség és pozíció számítása is, a lejátszás és minden egyéb, ja és persze az operációs rendszer minden ***-ával együtt, akkor ugyanott vagyunk mint a gyári cuccokban, hogy kell neki 2 gigás proci meg 1 giga memória.

Persze a programon lehet egyszerűsíteni, nem csinál az ember csillivilli pörgő lemezeket meg spektrumképet BPM számlálót stb, de a hangkártyáig nagy lesz a késés, mire minden kiszámolódik. Erre használják az Asio drivert, de olyan programba nem fognék bele, mert attól még marad a nagy gépigény.

Valami teljesen egyszerű, minden sallangtól mentes dolgon gondolkodom, amihez nem kell 19 colos monitor, meg skinek meg egyebek. Inkább minden funkciót bele a hardverbe ha lehet, kijelzés csak anniy kell hogy számcímek mondjuk. Az meg elfér egy monokróm kis LCD-re is.

Szerinem az STA DSP-t a rendszertől külön kéne kezelni valamennyire. A +/- időtartományban ráhagyással kell dolgoztatni... persze ez is csak egy kompromisszum. Tű áthelyezésnél sok idő kellene míg megszóllal a zene, mozgatásnál (gyorsítás) elképzelhető hogy kiürül a már feldolgozott WAV-ot tároló memória... ekkor megint kussolna míg be nem olvas. Szóval szerintem ez felejtős...

A CD-s megoldás: Itt is csak kereteket tudsz ugrani (amennyiben audio CD-ről van szó). Ha Play Audio ATAPI parancsot használsz, problémát jelent a puffer memória, ami mindég megy (nem lehet kikapcsolni). Ezért is nem értem miről karattyoltak néhányan, amikor azt mondták, hogy pl kocsiba nem érdemes beszerelni (ebben az üzemmódban a CDROM átlagosan 10-30×-os sebességgel olvassa az audio CD-t a pufferbe, ez az egyik legjobb rázkódásvédelem )
Visszatérve... ebben az esetben a PLAY AUDIO Command felejtős. (No persze itt is lehet feltenni egy SPDIF dekódert a kimenetre és I2S-ről dekódolni WAV-ba, de minek.) Mert sebesség állítási lehetőség nincs. Maradna a PLAY CD parancs, ekkor szükséged lesz egy külső pufferre, és hasonlóan az STA-s megoldáshoz +/- időráhagyással kellene olvasnod a CD-t (a legkisebb egység itt is a frame). Itt pedig jön a CDROM 100-120ms-os elérési ideje... tehát megint megakad...

A harmadik megoldás már egy járható útnak tűnik. A merevlemez elérési ideje töredéke a CDROM-nak (persze ha nincs töredezve, de ez ugyebár nem valósznű). Itt is csak a WAV, vagy valami más hasonlóan tömörítetlen formátum jöhet szóba.

Kössz a szakártő infót!

A CD-s megoldásnál egyébként arra gondoltam hogy a CD-n wav-ban lenne, és egyből betenni memóriába amit gyorsabban lehet elérni meg címezni. Tehát nem úgy akarom megoldani, hogy lejátszás közben kéne betölteni stb. Hanem előre egy memóriába bepakolni a wav word-öket.

Átalakítottam egy 9 perces mp3 számot wavba. 44 kHz 16bit stereo. A 12.6 MB os fileból 91.5 MB lett. Egy szám betöltésénél biztos vacakolna a gép 4-5 másodpercet de utána az egész menne RAMból. Ha lemondasz az XPről még egy 256 megával bíró gép is tudná kezelni ezeket a méreteket. Kellene hozzá saját szoft, de a hardware lényegesen egyszerűbb lenne sztem.

A baj az, hogy a lemezről jövő sebesség és pozíció adatok dekódolása szerintem eléggé igénybe veszi a processzort. Igaz még nem próbáltam ki. Mire a hangkártyán bejövő hangból szoftveresen kibányászom a tempót és a pozíciót. És utána visszaküldöm a hangot. És mindezt az oprendszteren át. Meg a memória elérés is oprendszeren át megy. Nagy a késleltetés szerintem. Legalábis ha ilyen könnyen menne nem kéne a gyári cuccokhoz ekkora gépigény.

Hi!

Tanulmányoztam a time code lemezen levő jeleket. A két csatornán ugyanaz a jel van. Kb 1333 Hz-es hullámforma. Kétféle amplitúdójú hullámmal. Egy nagyobb meg egy kisebb. Gondolom ez jelenti az 1-et meg a 0-t.
A két csatorna közt a különbség annyi hogy az egyiken kicsit késleltetve van a jel és halkabb. A késleltetésből nyilván azt lehet dekódolni, hogy előre vagy visszafele forog a lemez.

A time code úgy néz ki, hogy 17 hullám alkot egy kódot. Az első mindig nagy, aztán van 16 darab ami gondolom a tényleges pozíció kód, azt mutatja, hol járunk a lemezen.

Ebből kb 13ms-ra jön ki egy pozíciókód hossza. Tehát szerintem egy hangfájl ilyen 13 ms-os darabokra van tördelve és egyszerre ennyit lehet ugrani minimum.
Ebből az is következik, ha arréb rakom a tűt akkor addig az előző keretet játsza, vagy semmit, amíg egy teljes ilyen kódot be nem olvas a lemezről. Tehát legroszabb esetben majdnem 26 ms mire észhez tér.

Ha egy wav 44,Khz-es, akkor olyan 5-600 mintája ekvivalens egy time code kerettel. Magyarul 5-600 mintán belül nem lehet variálni, azt egybe lejátsza, betölti stb...

Ha kiszámolom az adatátvitel sebességét 16 bites sztereora ezzel a 600 mintával akkor 200KB/sec-el kell a memóriából a lejátszó pufferbe nyomni nagyjából az adatot.


hát eddig ennyire jutottam.

Egy hasonló dolgot építettem magam is, bár a vas része csak MIDI adatok fomájában küldi tovább a lemezjátszó adatait. Ha nem ragaszkodsz az abszolút időhöz, akkor elegendő egy fix szinusz jelet levenni az egyik csatornára, a másikra pedig 90 fokban eltolva ugyanazt a frekvenciát. A frekvencia méréséből megtudod a sebességet, a két jelből pedig az irányt.
Frekvenciamérés: PIC CCP moduljába félhullámú precíziós egyenirányító után. Méred két nullátmenet közötti időt egy CCP modullal, majd egy osztás után megkapod azonnal a sebesség arányt.

De persze a te esetedben fontos lenne az abszolút idő. Van egy MsPinky nevű rendszer. Egy nyílt forráskódú Max/MSP-s program. Ezt használják többek közt a M-Audio Torq nevű rendszerében. Ingyenesen letölthető néha a béta verzió az egyik fejlesztőhonlapjáról. Mivel a Max/MSP grafikus felület, ezért egész jól meg tudnád nézni az algoritmust, és fel tudnád használni.

Jól látod, a legtöbb timecode-os rendszer 13-20msec-et csúszik, amihez még hozzájön a hangkártyák min. 8-10 msec latencyje. Ha kevesebb latencyt emlegetnek, akkor az csak marketing. Ahány szoft, annyi féle képpen oldják meg. A keret ideje persze változó,mivel a lemez sebessége is változó.
Én ezért maradtam az egyszerűbb megoldásnál. Nem tudoma tényleges időt, viszont a sebesség és forgásirány infókat minden egyes nullátmenetnél megkapom.

Sok sikert!

Hi!

Igen, nekem kéne az abszolut idő. A frekvenciát azt suerintem egy interruptos komparátoros megoldással is meg tudnám mérni, de AVR-el akarom, azt jobban szeretem.

Két kérdésem lenne, Mi a CCP modul a PIc-ben? rakoztam velük sokat de ez nem rémlik.

A másik pedig a MaxSP micsoda? Programnyelv?
Köszi a tippet, majd belenézek a kódba hátha valami hasznosat találok.

A CCP Compare/Capture/PWM modul. Capture módban egy Schmitt triggeren keresztül az egyenirányított analóg jel a PIC CCP bemenetére kerül. Egy számláló fut folyamatosan. Amikor érkezik egy impulzus a CCP lábra, akkor egy megszakítást generál a PIC, és áttölti egy 16 bites regiszterbe a számláló értékét. A számlálót ezután nullázom. Így minden nullátmenetnél tudni fogom a sebességgel arányos periódus időt. Az időzítő órajelének értéké elosztom a fentebb kapott idővel, és Hertz pontosan megkapom a frekit.

A Max/MSP egy grafikus programozói felület, elsősorban kísérleti kép/hang előadásokra használják, és szoftver fejlesztésre.
http://www.cycling74.com/products/maxmsp

Tulajdonképpen egy moduláris fejlesztői rendszer. Kicsit mélyvíz, viszont cserébe meg tudsz tekinteni belülről egy működő rendszert, amihez hasonlót szeretnél csinálni.

Ha elfogadsz egy tippet, mindenképpen több proceszoros rendszerben gondolkodj, már az elején. Egy mikrovezérlőt biztos elhasznál a timecode feldolgozása. Pl. SPI-n tudna két mikrovezérlő kommunikálni. Már csak azért is javaslom, mert eléggé időkritikus a feldolgozás, és kétlem, hogy egy AVR-rel meg tudnál mindent oldani.

Ja, és I2S-en elküldeni a hangot sem piskóta, márcsak a sebesség miatt is. Kb. 1,5MB/sec adatot kell előállítanod, ráadásul egy normális resample algoritmus sem piskóta. A helyedben szétnéznék DSP fronton. Bár nem értek AVR-ekhez, nem tudom mennyire optimális megoldás DSP algoritmusokhoz. dsPIC-ekkel talán megoldható már a dedikált utasítások miatt, de 44.1kHz/16bit jó minőségű feldolgozásása lehet megenné. Ti DSP-ket már egész olcsón lehetne venni,csak a fejlesztési költségek rendesen megugranának.

Szerintem előbb próbálj egy szoftvert írni, majd ha ott tökéletesen működik, akkor elkezdeni hardverben gondolkodni.

Hi!

Akkor tudom mégis mi a CCP csak a három betűs rövidítését nem Az AVR amúgy dettó olyasmi mikrokontroller mint a PIC-ek úgy átlagban, mármint teljesítményre. Kevesebb tipus van, meg nekem jobban fekszik.

A több proci az alapvető. Csak még pontosan nem tudom mit is akarok Sajnos a CPLD panelem eladtam, azzal a memória töltögetés elég gyorsan menne. De egyelőre még csak körbejárom a témát.

Szoftvert azt nem akarok írni. Úgy értem hogy PC-re. Nem akarok semmi PC-s mixert meg minden felesleget kivenni. Ha lemezjátszózik az ember, akkor felesleges hogy ott pörögjön villogjon meg spektrumképezzen nekem. A normál lemezen sincs spektrumkép bpm stb... (Persze azért egy kiállás vagy a szám vége látszik a barázdákon annyival jobb) Ha lehet, akkor a zenéket is inkább egy saját vinyó tárolná, és semmi PC nem is kéne hozzá. Vagy maximum arra, hogy USB-ről átnyomja a célhardverre. Tehát tényleg csak a feltétlen szükséges funkciókat.

1,5 MB/sec szerintem nem kell, akárhogy is számolok. Resample algoritmus meg talán van valami audió DAC-ba integrálva. Még kutakodok hogy is lenne jó és olcsó. Ha lenne egy izmos laptopom, amit nem sajnálok, akkor nem is foglalkoznék ezzel

A szoftvert csak azért írtam, mert az algoritmus megírása nem lesz egyszerű, és könnyen megeshet, hogy a kellő teljesítményhez valamilyen DSP-re lesz szükséged. PC-n tesztelni egy algoritmust mégiscsak egyszerűbb, mint célhardveren.

Elsőnek feldolgozod az analóg timecode jelet, majd a bufferbe olvasott WAV adatot a timecode információi alapján resample algoritmusra engeded. DAC-okba nem is, de a vevő IC-kbe integrált cucc csak mintavételi konverzió, többnyire csak a szabványos értékek között. Tehát 48-ről 44,1-re stb. Bár nem néztem utána.

A lineáris interpoláció szerintem felejtős. Legalábbis minőség tekintetében mindenképp. Helyette pl. olyan algoritmusra lenne szükség, ami pl. lassításnál üres helyeket szúr be az audio jelbe, majd egy FIR szűrőn átengedve előállnak a hiányzó jelek. A http://www.musicdsp.com oldalon találsz pár egyszerűbb algoritmust.

Ezért írtam a 1,5MB/sec-et, mert az algoritmust procin kell futtatni, ahhoz pedig a fenti értéket kell hangilag előállítanod.

Nem lehetetlen megcsinálni, tényleg jó lenne vasban (Numark meg is csinálta, belső vinyóval, meg MMC, stb.) de szép nagy fába vágtad a fejszédet.
Csak szurkolni tudok, hogy meg tudd csinálni, de ha csak az izmos laptop a gyenge láncszem, akkor azt hiszem jobban jársz ha veszel egy gépet.

M-Audio Torque-ot és DVS-t próbáltam, egyáltalán nem kell izom gép nekik. 1,5GHz mobil cerkán 512MB RAM-mal gond nélkül mentek.

Azért bevallom, igencsak kétlem hogy 20-40MHz-es procikkal megoldható a komplett processzálás. A timecode feldolgozására önmagában is FFT lenne a legkézenfekvőbb, de ahhoz minimum dsPIC kellene. És a resample még legalább 1 chip lenne.

Kivétel nélkül, minden gyártó néhány száz MHz-es DSP-vel szokta megoldani az ilyeneket. Gyors fejszámolás, 40MIPS-es procival minden hangminta előállítására 26 utasítás jutna. Ez elég lehet (hardveres 16 bites szorzót használva) a resamplinghez, de a timecode feldolgozása már nem.

Ha van ötleted, vagy tudok valamicskét segíteni írj, a téma engem is érdekel.


u.i.:http://www.musicdsp.org/archive.php?classid=0#212
Ezt most találtam.

Helló!

A DPS-khez nem értek még egyelőre. (Bár hallgattam egy fél évet, de semmire se volt jó) A time code feldolgozáshoz is külön procit akartam. De lehet hogy egy DSP tényleg egyben megoldhatná. Esetleg még FPGA-ban gondolkodom, de akkor hardvert kéne kidolgoznom a time code-ra meg a resamplingra is és az szerintem bonyolultabb mint egy C kódban megírni.

Egyelőre a legnagyobb fejtörést az okozza, hogy hogyan is állítsam elő azt a 50-80Mb-os wav fájlt másodpercek alatt a memóriába.

Érdekelne egyébként hogy mire használod a midis megoldást, ami csak sebességet meg irányt szolgáltat. Csak ilyen jog-ként működik akkor a lemez valami mixelő programmal?
A vinyl-t te vágattad hozzá?

Vinylt nem vágattam, odáig még nem jutottam el. Egyenlőre csak CD-n van hang hozzá.

A MIDI adatok szabadon felhasználhatók, effekt vezérlésre, tempóhoz, stb. Több különböző üzemmódot írtam, és egy LCD kijelzőn jelennek meg az információk. Elsősorban Ableton-hoz lett tervezve a tudása.
Itt egy kép a demó verzióról:http://www.hitspace.hu/images/users/blogs/2129.jpg

A googli nem találja az MsPinky forráskódot. Sajnos az mspinky-com se jött be valamiért. Lehet hogy emgszünit az oldal. Pedig érdekelne. Elképzelhetőnek tartom, hogy akár a gyári rendszerekhez hasonló módon is mehetne a cucc egy kisebb gépen. Csak a fölösleges dolgokat, amivel feltuningolják, azokat kéne kihagyni. (Vagy újraírni) Tehát semmi grafikus felület

A MsPinky az egy szimpla plugin, semmi sallang, natúr, 100%-osan működő rendszer. Épp ezért mondtam, hogy nézz rá.
Holnap előtúrok pár DVD-t, és megkeresem a Max/MSP-s forráskódját. Nekem sem jött be az oldal, de a Cycling '74 oldalán van pár infó.
http://www.cycling74.com/products/mspinky

Értem, kezdem felfogni a leírásból A kód mindenképpen érdekel, ha nem lehet egy bitet se lefaragni belőle akkor is. (Azért a spektrum kép itt is befigyel)
A végcélom az lenne hogy ne kelljen vennem egy új laptopot, mert van kettő is amiket nem sajnálnék buliba hurcolni ilyesmire. Viszont egy zsír újat nem áldoznék fel. Szóval úgy 256MB RAM és 750Mhz áll rendelkezésemre sajnos. Meg amúgy is érdekelt régóta hogy működnek a vinyl control rendszerek.

Na, működik az mspinky.com. Kétféle fejlesztői cuccot láttam megemlítve. Egy SDK-t amihez Fan club tagság kell (nem ingyenes magyarul), meg ezt a MAX/MSP-s dolgot, de letölthető cumó sehol nem volt eddig.

Hi!

Bocs, nem volt időm hamarabb feltölteni.
A Cycling '74 oldaláról le tudsz tölteni demo Max/MSP-t, plussz kell majd hozzá Pluggo Runtime Library, ez utóbbi azt hiszem ingyenes. De van egy readme.txt fájl, azt nézd át.

Üdv, Tamás!

Sziasztok!

Nekem is eszembe jutott a Timecode rendszer építés, és nincs sok pénzem, tehát a következőkre jutottam:
Egyszerű keverőt egyszerű csinálni.
Lemezjátszó: Vennék egy lézeres, USB-s egeret, amit egy forgó lemez alá raknék. Már csak a szoftver problémás. Én egy VirtualDj-hez (http://www.virtualdj.com/) hasonló szoftverre gondoltam (a díszes Skin nélkül), ami az egér mozgása alapján játszaná le a memóriába kicsomagolt zenéket. A probléma az, hogy a gépre kötött mindhárom egér mozgatni szeretné az egérmutatót, kettőt valahogy tiltani kellene.
Ennyi az ötlet, monjátok el véleményetek, nagyon érdekelne.
Egy kérdés: A MIDI porttal mit lehet kezdeni, és hogyan? Én eddig csak joystickot kötöttem rá.

Üdv. Muri!

Működhet, pontosabban láttam már hasonlóvideót a Youtube-on. Azt viszont nem tudom, hogy három egeret hogy lehet a gépre kötni, ugyanis (tudtommal) csak egy kurzor lehet az asztalon.

Nálam a hangsúly nem igazán a timecode-on volt, hanem egy olyan MIDI kontrolleren, aminek a bejövő jele egy lemezjátszó forgásának paraméterei, a kimenetek pedig szabadon felhasználható MIDI Control-Change paraméterek. Effektek vezérlése (pl. szűrő, granular sampler, stb.), vagy konkrétan egy zenei applikáció tempo paramétere, amivel így külső jelforrásra is pontos tempóban illeszthető.

A bejövő MIDI adatokat utána már szoftveresen (Reaktor, Max/MSP) tetszőlegesen lehet felhasználni.

Ne keverd össze a MIDI és a Joystick portot. A kommersz hangkártyákon helytakarékosság miatt egy csatlakozóra került (15 pólusú SUB-D) a MIDI és a Joystick.
A MIDI ebből mindössze 2 pont, az RxD, és a TxD. Meg persze egy GND pont is kell azért. Sima egyszerű 32,15kbit/s aszinkron soros port. A szabvány szerinti MIDI csatlakozó 5 pólusú Tuchel, amin 2 vezeték szerepel. Plusz a kimeneti oldalon az árnyékolást földre kell kötni.
A MIDI azért jó, mert szinte minden zenéhez kapcsolódó szoftver ismeri, tudja kezelni a rajta beérkező üzeneteket. A MIDI kontroller pedig megint nem egy nagyon bonyolult hardver. Hogy konkrétan ki-mire használja az teljesen a felhasználóra van bízva.

Amit Gory szeretne, hogy egy standalone külső hardverbe timecode-os vezérlésű MP3 lejátszót épít. Van egy olyan érzésem, hogy DSP nélkül nem fogja megúszni. Maga az analóg timecode jelnek a feldolgozását nem lehet DSP-re optimalizált proci nélkül megcsinálni. (mellesleg fejlesztési költségben is ott lenne a végén, mintha venne egy használt laptopot)

Sziasztok!

Újra előszedtem a témát, boncolgatás szintjén csak. Ahogy néztem az MsPinky leírását, az a szoftver komponens szintén nem direktben mp3-al dolgozik, hanem PCM formátumú audióval.

Néhány új ötlettel gyarapítanám még a témát. Egyik, hogy mostmár nálunk is beszerezhető mp3 konverter IC a VS1001. Tehát az mp3 konverzió cél IC-vel viszonylag egyszerűen menne.
A lemezen a tű áthelyezése nem jelentene olyan nagyon nagy gondot, mivel ki lehet számolni hogy melyik frame tartozik az mp3-ból ahhoz az adott időpillanathoz. Ebből pedig hogy melyik bájtok kellenek a fájlból.
Csak az a kérdés mennyi időbe telik pozíciót számolni, abból pedig a megfelelő bájtcímet, és ezalapján átnyomni a dekóder IC-be a bájtokat.

Igaz ez mind gyakorlatilag direkt mp3-ból dolgozik, és például VBR mp3-nál nem járható út.

Sajnos arra a megállapításra jutottam megint hogy PCM audió kell és egy nagy memória. Ezenkívül egy gyors mp3 dekódoló algoritmus, ugyanis szerintem ez a VS1001 csak nagyjából a lejátszási sebességel dekódol. Az meg 3-5 perc lenne ami elég használhatatlan.

Ja kihagytam a legfontosabbat. Szóval mivel sztereóban megy a dolog, és a sztereóban nyilván a két csatorna egyszerre szól, ezért elég két darab fele akkora memória is mint a tömörítetlen wav file. A két memórián pedig párhuzamosan ugyanazokat a műveleteket kell csak végrehajtani.

Ha felteszem hogy max 10 perces számokra tervezek, akkor 16 bit 44,1KHz esetén nagyjából oldalanként 50MB memória kell.

Sziasztok!

A topic sokat pihent, pedig érdekes a feladat.
Gory:

Nem feltétlenül!
Ha nem csomagolod ki az egészet, hanem csak a lejátszás pillanata előtti és utáni 10-20 másodpercet, akkor viszonylag kevés is elég.
16 bit 44,1 KHz esetén egy frame 32 bit (4 bájt), ebből van 44100 tehát az 1411200 bit (176400 bájt, 172,265625 kByte). Ha 30 mp-et csomagolok ki, az 5,014... MByte (40,37... Mbit) , ami jelentősen kevesebb. (Remélem jól számoltam.)

Szerintem egy lehetséges megoldás, hogy a gépből USB-n keresztül (pl. PIC18F4550 12Mbit/s-os USB-vel ) betöltöm a wav-ot egy "video memory"-ba, ami elég gyors (néhány ns! egy írás/olvasás), és (ti.com) van belőle dual portos is. Az egyiken keresztül feltöltöm, a másikon keresztül pedig egy dsPIC intézi a lejátszást. A dsPIC pedig valahogy jelzi a másiknak, hogy hol tart (pl. beleírja a memóriába). A folyamatos lejátszáshoz elég 1,4 Mb/s-os kapcsolat, tehát a 30 mp zenét betölthetek a memóriába 3,5 másodperc alatt. Ha nem tudom a teljes sebességét használni az USB-nek, akkor is csak néhány másodperc.
A dsPIC vezérlésére lehet használni rendes bakelitet, de én egy optikai egér szenzorát használnám, mivel a lemezjátszó szerintem drága, és viszonylag bonyolult szerkezet, mellesleg nem fér be egy hátizsákba.
Az mp3-at a számítógép csomagolná ki.

Muri

Nálam adott a lemezjátszó
Igaz hogy elég részlegesen betölteni a fájlt egy memóriába. De van hátránya is. Például ha arrébrakom a tűt, akkor ismét be kell tenni egy teljesen új részt, és ez idő.
Ezenkívül mondjuk ha nagyon felgyorsítom a lejátszást, vagy nagyon gyorsan beletekerek a lemezbe, akkor meg kell gondolni, hogy mekkora legyen ez a buffer.

Annyi egyszerűsítést lehet még csinálni, hogy alap lejátszásnál nem kell az abszolút pozíciót figyelni, csak a sebesség/irány adatokat. Ezt meg elég sűrűn lehet mintázni, hiszen csak a két fázistolt jelet kell nézegetni, nem pedig egy komplett kódszót. Ha viszont néhány ms ideig nem jön jel, aztán újra jön (arrébraktam a tűt), akkor kell egy pozíciót számolni, betölteni kellő menyiségű adatot a bufferbe pre és post egyaránt és mehet tovább a relatív pozíció nézés.

Egy másik nehézség, hogy ha nagyon durvul az ember, akkor simán az alap sebesség 3-szorosával is cibálhatja a lemezt, és erre fel kell készülni. Akkora pre és post buffer kell, hogy mondjuk egy mozdulattal ne tudjak akkorát rántani a lemezen hogy kifogyjak a bufferből (tehát 8-10 másodperc azért kell előre is hátra is)
És a pointer még jócskán a buffer közepén járjon.

Ami a maximális sebességet illeti az mondjuk +-16%-ra lehetne optimalizálni. Tehát kb 52KHz-en tudni kell lejátszani és tölteni a buffert (amibe az mp3 dekódolás is beletartozik). A nagyon gyors mozdulatokra talán a bufferméret ad garanciát és nem kell olyankor. De ezt át kell gondolni hogy lehetséges-e úgy cibálni hogy kifussunk a bufferméretből.

A PIC 18F4550-el szerintem elég lehetetlen dolog ezt a 12Mb/s-ot elérni. Vagy legalábbis én nem tudom hogy milyen USb osztályt kell hozzá használni. A CDC és a HID egész biztosan kilőve. Talán a Mass Storage Device tudhatja ezt.

Én különálló hardverben gondolkodtam eddig, de ahogy most látom, az mp3 dekódolásról le kell mondanom, mert valós időnél gyorsabban sajnos nem nagyon megy. 15-20 másodpercnyi szünet pedig elég sok mire feltölti a buffert a dekóder.

Hacsak valahogy nem lehet ezt egy trükkel megoldani. Esetleg ha olyan kompromisszumot köt az ember hogy +- 6 másodperc a buffer. És mondjuk két dekóder IC-t használok, egyet előre irányba egyet meg reverse. Menet közben pedig valamilyen stratégia szerint lehet esetleg mindkét IC-t ugyanabba az irányba dolgoztatni.

Egy újabb probléma az, hogy 48KHz-et tud maximum a VS1011 amit itthon be lehet szerezni. Ez meg ugyebár csak +8% tempóállításhoz elegendő. Egy technics mk2-nél ez nem para, mert ott a pitch poti +-8%-ot tud szabályozni, szóval ezt a kompromisszumot is talán meg lehet kötni.