新しいオモチャをゲットした

amazonに頼んであったyamaha pss-a50 が本日到着

まあ半世紀近くも楽器に触れてない上にギターじゃないわけで全く引けないけど楽しい。
特にDominoと連携して新しい試みをするのは面白い。
まだできてないけどアルペジエータでMIDIを作ったり出来るかとか考えるだけで楽しい。

当分は楽しめそうだ

(210412)
追記
A50のMIDI機能でDominoでいろいろ試してみたいと思ってたけどレイテンシがきつくて入力がつらい。最初は200ｍSぐらい遅いと思ったけどいろいろやって50mSぐらいになったけどやはりリアルタイムで引くのはちょっと
（ほとんど引けないけどコード長押しすら遅れるのでは・・・）
Dominoのせいかわからないので一念発起してCakewalk by Bandlabを入れてオーディオ側にもDominoでも試したASIO4ALLをoption選択したら気にならないくらいにはなった。
a50のタッチレスポンスが引く力に対して効きすぎるので当分はoffにする
CbBの画面の情報量に圧倒されつつ当面は初心者だね。

20年遅れ

 最近、DTMに目覚めつつある

DTMとは - DeskTopMusicの略で主にPCなどの助けを借りて音楽を制作することを総称する和製英語
90年代後半から2000年代に流行ったMIDIをデータ授受の中心に据えた音楽制作を指す

当時はMIDI音源と呼ばれるGM音源規格のジェネレータが存在したがPCのソフト音源に取って代わられたのだがここWindows10になってMIDI自体の重要性が薄れてデフォルトではあまり褒められた音では無くなった

しかしである、何故か目覚めたんだね
このMIDIで鳴らすDTMに
この場合のWindowsのオススメのソフトはDominoらしい

最近ではDAW(Digital Audio Workstation)と呼ばれる本格的なEffectやプロが使うようなソフト音源やデジタルで録音された生音を組み合わせてスタジオなみのことが出来る環境もあってCakewalk by Bandlabというソフトなどはもともと有償だったものがフリーになっていて素晴らしいのだけどその分いろいろと操作も複雑になるのでまずはDAWからみればよりプリミティブなMIDIのDTMをやってみようってわけだ（まあ自己満足だね、さほど才能ないし）

まだまだ人様に聞かせるようなものとは程遠いものをポチポチマウスで入れているんだけどそのうちにここでも披露するかも

IDEが好き

IDE・・Integrated Development Environmentの略　統合開発環境の意味 Wikipedia

PCでいろいろな言語を触って遊ぼうと思うと不可欠だと思う環境
特にエディタでコード支援が無いとまともに書けないへっぽこプログラマなので不可欠

またGUIの設計ツールも欲しいので余計にIDEにこだわることになる

最近は仕事はWindows、空いた時間の趣味はmacbookと棲み分けているので言語をいじるときは両者で動くIDEが良いと思っている
MSのVisual StudioはmacではC#のGUIが共通で動かないので残念
スクリプト系は最近はvisual studio codeで書くことが多い

以前実験的に使っていたSmalltalkのPharo（もしくはSqueak)とJavaのNetbeansに再び食指を伸ばそうかと思っている(いずれもmacでもWindowsと同じ様に動く)

さてどうしようか？

(210308) 追記
　そもそもmacとwindowsであまり違いを感じずにいろいろなソフトの記述を共通化して楽しむのならむしろpythonによるシステム開発的なものの統合化を図る方がずっと面白そう

python+tkinter( or pysimplegui)+openpyxl+SQLAlchemyぐらいを自由に使えるようになればかなり面白い環境が構築できるかもしれない

MSXで・・

 何するわけでもないけどとりあえずその「遅さ」を体感してみた。

題材はretro-pcさんもご利用のmandelbrot風のasciiart

msx-basicでやってみた。手元に実機もないのでオンラインのエミュレータwebMSXで
(最初横の文字数が40文字しか出来ないと思って別バージョンを作ろうとしていたんだけどmsx-dosでmode 80って言うのがあるんで調べたらscreen 0でwidth 80でいいんだ)

最下行に所要時間を表示させてるけど実は何度も試すのに嫌気が差してスクロールで隠れる2行ほどを端折っているのでその分下駄を履かせた感じで時間が短くなっている。

本当の所要時間は838.217秒(13分58秒217)となる。

遅い原因はデフォのエミュレート機能はz80の3.58MHzクロックを忠実に再現しているからだと思う。(検証してないけどもしかしたらメモリーアクセス時のウェイトまで）

その上MSX-basicは10進計算で浮動小数が特に遅い。

同じWebMSXでcp/mの各言語でも同様の処理を走らせて比較してみると・・

mbasic 8分45秒

上記をBASCOMコンパイラにかけた実行ファイルだと 3分15秒弱

turbo pascal 3.01の生成する実行ファイルだと 4分11秒

hitech-c で生成したオブジェクトだと 2分9秒強

となる、最速のhitech-cを1とすると

hitech-c : bascom : tp3 : mbasic : msxbas =1 : 1.5 : 1.95 : 4 : 6.5

まだz88dkのcのオブジェクトとhitech-cのそれを比べてないけどcの優位性って凄いな

（まあ同じ処理を書ければだけどね）

ちょっと楽しいのでしばらくあれこれ実験をしてみようと思う。

(webMSXは[ALT]+[T]でCPUの[ALT]+[Y]でVDPのクロックを最大8倍までコントロールできるので実験段階やマンデルブロー集合描画のように結果が早く欲しいときは重宝しそうだ。）

ちなみに両方8倍にして昨日実験のhitech-c版のasciiartは15秒で書き終わる、素晴らしい

さらにz88dkのzccで作成したものとhitech-c版を比べてみたらzcc版は30秒ほどと2倍近くの時間がかかった　浮動小数を用いた演算が処理の大半だと思うのでライブラリーの差なのかな

hitech-cはプロンプトに対して c -v filename.cでfilename.comを生成してくれる。

(コンパイル環境に生成される実行ファイルが結構影響されるturbo pascalと違ってwindowsでcp/m playerを使ってコンパイルしてもcopyした先の環境ですぐに走る。)

z88dkの場合はzcc +msx -subtype=msxdos filename.c -o filename.comって感じだ。

実行の名前は変えられるので同じソースをコンパイルするときはfilename.comの部分を変えればよし。

z80とクロス開発環境z88dkとオブジェクト指向設計実践ガイドとrubyとpython

 随分「と」が多いタイトル

ちょっと前からあれこれcp/mのエミュレータなどを通してz80のプログラムをいじることがあった（まあ言語を通してだから直接アセンブラなどで弄ってるわけではないけど）
で、せっかくz80を考えるのならグラフィックなどに反映するのも面白いと思ってwindowsやmacOSでクロス開発環境を探していたらz88dkに出会った

z88dkはc言語とアセンブラなどでcp/mやMSXやPC-6001やSharp X1などを対象とした利用メディアに応じたアウトプットを選ぶことのできる開発環境

試しにDLしてgnuMakeと組合せてExampleの内容をコンパイルしたらMSXで動くサンプルとかがたくさん得られた。webMSXって言うonlineのMSXエミュレータで動かしてみるとちゃんと動くので感心した　やはりグラフィックがあるとモチベーションが上がる

自分のOOP力を上げるために「オブジェクト指向設計実践ガイド」を読み始めた
副題が「Rubyでわかる進化しつづける柔軟なアプリケーションの育て方」なので一義的にはrubyで写経しつつ本文を理解してpythonでポーティングして理解を深めたい
※あって良かったWSL

しばらく上げてなかったのでまだまだ塊にならない実験しかしてないけどちょっとメモしておく

macでpascal - 過去の栄光と現在の挫折

最初に覚えたPC言語はBASICをだった。
当時はそれしか選択肢がなかったのだが今思えばもっと早くに卒業すべきものだった。
で、その次に覚えて大きな影響を受けたのがturbo pascalだった。
当時のバージョンは3.0.1くらいのころで各社のMS-DOSで動く仕組みを作ったものだ。
（まあ主にNECとFujitsuだけど）
使いやすいし勉強にもなった。

で、最近macbookでいろいろ実験をするうちにふとfree pascalをいじってみたいなって考えて、ついでにGUIも出来たらいいなって余計な欲をだしてLazarusの最新を入れてみた。
そう言えば初期のmacの公式開発言語はobject Pascalだったと思いだしたり・・

C#とかの知識をもとにいきなりimageのcanvasを塗りつぶすって簡単な数行のソースを書いてrunアイコンをクリックしたら threadの絡むエラーを吐いた。

どうしてエラーが書いたソースから離れた箇所から出たかググルにもLazarusでは情報が少なくて困難な感じだ。今後のことを考えて早速の挫折。
以前はWindows上の古い版でmandelbrotの描画をしたりしていたのだから色々調べながらなら書けなくは無いのかもしれないけどmacのお遊びでそこまで踏み込みたくない気もして速攻でapplicationフォルダからリンクをけしてLibrary以下の本体もゴミ箱行きです。

pythonならnumbaやpygameもあるので潔く諦めて過去の栄光に浸るのはやめよう。

久しぶりにハマった

 Excelでmandelbrot集合の描画をする実験が思いの外うまく行ったので気を良くして普通の直線を描画するアルゴリズムを実装しようとしていたんだがここでハマってしまったのでメモ

画素を指定して点単位で色を着けられる画面（つまり今回のExcelのセル幅と高さを1ピクセルに調整してセルの背景色で色を着けられるような場合）マンデルブロのように各点ごとに条件を計算して色をつければ完成するようなものよりも直線の描画のように始点と終点をしていして（必要なら色の指定もして）描画するような操作や中心と半径を指定して円を描画するようなプログラム部品が欲しくなる。

そして直線をなるべく少ない計算量で描画するのがブレゼンハムのアルゴリズムである。
ここで事件は起きた。
まずは手持ちの資料がCだったのでそれを逐語訳的にVBAに置き換えて動かして見た。直接デバッグウィンドウに
drawline 0,0,639,479,vbRed
のように打ち込んで実行するときれいに直線が描画される。しかし
for x=0 to 639:drawLine x,0,639-x,479,vbBlue:next
 等とするととたんにおかしくなる。ｘの区間がある程度までは問題なく描画されるのだがx=80ぐらいから妙なことに画面の中央ぐらいでチラチラするだけでうまく行かない。

単一行だとうまくいくのに連続の実行だと変になる。最初はわけが分からなかった。
ソースをながめること小一時間。あれこれ、パラメータを受けてそのまま作業変数として使ってるぞ。そうか参照渡し（もしくは変数渡し）と値渡しの違いなのか。

Cとかpascalとかは値渡しが基本です。渡された関数(pascalだとprocedureもありね)はパラメータを内部処理でローカル変数と代入し合ったりしても渡したもとのプログラム側では値が変わってしまうことは値渡しということで無い。しかしvbaは基本的には参照渡し。
つまり上記のforの例のように繰り返し管理に使うｘの値が途中で変わってしまって上手く行かなくなったようだ。

ここまでわかれば対策はかんたん。関数(手続き)側のパラメータ宣言部の変数に前にbyvalを付ければ目的は果たせるのだけど今回は呼び出し箇所が1箇所だったので
for x=0 to 639:drawLine (x),0,(639-x),479,vbBlue:next
みたいに呼び出し側で式化して値を渡すようにして逃げた。

仕事で各プログラムだと繰り返しの変数を直接パラメータに渡すような処理を書くようなことがまず無いせいですっかり忘れてたが副プログラムの処理で変数の内容が変わるような副作用を起こせたんだ。やはり基本的な(そして大事な)変数まわりの処理や副作用には常に気を配らねばと思った。

日が変わってやっぱり呼び出し側に気を使わせるよりは手続き側のパラメータ指定にbyValをつけるほうが呼び出しのたびにコピーが生じるとしても正しいと考えて手続きの冒頭を
sub drawline(byVal x1 as integer,・・・・,col)
のように書き直した。
将来の自分が呼び出し側で今回のような配慮や工夫が必要って覚えている保証無いもんね。