Jonkinverran nyt tuota säätäneenä lopputulema ainakin omalta osaltani on että tuo Pure Data on paras/helpoin ratkaisu, eikä se vie käytännössä yhtään prossua/muistia kun ei ole edes audiot (DSP) päällä.
Ensin kokeilin [shell] -objektia "ggee"-kirjastosta, mutta jostain syystä PD ei osannut luoda sitä automaattisesti patchia avatessa ja se piti aina manuaalisesti luoda uudestaan. Taisi siinä olla jotain muutakin mätää, ehdin jo unohtaa mitä.
https://github.com/pure-data/pure-data/issues/1697Sitä oli sitten joku korjannut ja tehnyt [command] -objektin, joka toimiikin hienosti ainakin suorilla komennoilla. Viiveen pituus jostain syystä vaihtelee, joskun harvoin sekunninkin, useimmiten onneksi vain murto-osa, mikä on ihan siedettävä peruskäytössä.
https://github.com/pd-externals/commandEnnestään oli tiedossa systeemin (alsa midi driver?) ongelma: konetta bootatessa tai usbeja kytkiessä midi-porttien tunnisteet voi vaihtua ja silloin PD:ssäkin viestit menee vääriin osoitteisiin tai ei mihinkään. Päädyin siksi tekemään samaiseen patchiin automaattisen porttien yhdistämisen käyttäen alsan "aconnect"-komentoja jotka ei ole niin tarkkoja porttien numeroista, riittää kun nimet on vähän sinnepäin. QjackCtl-graafista voi seurata kun portit yhdistyy automaagisesti.
Yritän vielä selvittää miksi PD kadottaa tulevat midi-viestit joskus kun koneen herättää nukkumasta. En oikein löydä logiikkaa tuosta, "aseqdump -p device:port" -komento näyttää että viestejä tulee, ja vaikka teen uusiksi kaikki kytkennät (manuaalisesti QjackCtl, tai komennoilla PD:stä) silti PD:n midi-inputit on mykkiä. Tilanne raukeaa kahdella vaihtoehtoisella tavalla: joko midit vain alkaa jossain vaiheessa itsekseen kulkea, tai sitten PD muuttuu epävakaaksi (monenlaisia pieniä bugeja editoinnissa) ja sitten kun yhteys syntyy, kone menee välittömästi nukkumaan (!). Tämän jälkeen kun koneen herättää, midit ja komennot toimivat heti. Vähintäänkin hämmentävää. Viestit jää oletettavasti johonkin (ajurin?) bufferiin ja pärähtää purskeena kun yhteys syntyy. Tämä on ärsyttävä jumi koska yleensä koneen herätettyäni haluaisin ensimmäiseksi painaa "play".
Toinen ongelma on että jotkut komennot jää "päälle", PD ilmoittaa "old process still running". Tämä on todennäköisesti omaa syytäni kun en ymmärrä täysin tuon [command] -objektin sielunelämää, sen help-fileestäkin menee suurin osa yli hilseen... mikä ihmeen FUDI parsing?
Bonus: ainakin omassa systeemissäni on ominaisuus (kuulemma bugi) joka estää näytön/koneen nukuttamisen näppäinkomennoilla, järjestelmä tulkitsee näppäimen noston herätykseksi eli unet jää varsin lyhyiksi. Tämän pystyn nyt kiertämään triggaamalla komennot PD:stä: ohjelmoin molemmille nukutuksille oman liukusäätimen siten että säädin asettaa ajan jonka kuluttua PD:lähettää käskyt systeemille. Tämä ei toki mitätöi kyseisille toiminnoille virransäästöasetuksissa säädettyjä arvoja, (jotka olen nyt asettanut aiempaa pidemmiksi), luonnollisesti vain niitä lyhyemmät ajat toimivat. Kokeilin ensin säätää komennoilla suoraan systeemiasetuksia (esim: sudo systemctl mask sleep.target jne) mutta en saanut toimimaan. Tämä on itselleni siedettävä kompromissi.
Periaatteessa olen siis saanut Quod Libetin perustoiminnot (ja vähän muutakin) tyydyttävästi midi-ohjaukseen. Pari kaipaamaani toimintoa vielä uupuu koska niille on vain näppäinkomennot, ja siihen näköjään tarvitaan lisää softaa (xdotool). Ehkä testaan sitä myöhemmin muillekin softille kuten nettiselaimelle.
Tämä on itselleni varsin mielenkiintoinen aihe muutenkin kuin vain Quod Libetin osalta, koen tässä olevani jotenkin tietokoneen tarkoituksen ytimessä: miten tehdä monimutkaisia/usein toistuvia asioita yksinkertaisesti. Ei tarvi haahuilla hiirellä, selata valikkoja, avata terminaalia, muistaa näppäinkomentoja, ei tarvi olla edes näytössä kuvaa. Riittää kun painaa kerran yhtä nappia.
Jos joku on jotain vastaavaa säätänyt niin olis kiva kuulla kommenttia.
Aihe: Komentojen tai skriptien triggeröinti midillä (Luettu 3595 kertaa)
