COMMONでそんなことが(これも初耳情報)。 CLIPBOARD使った場合のカレントプロジェクト対処方法まとめておきますね(本命じゃないけど)。 1).下記プログラムをSLOT3とかに置いとく。 COMMON DEF CD PJ$ PROJECT PJ$ PROJECT OUT PJ$ CLIPBOARD PJ$ END 2).RUN 3実行し、以後PROJECTの代わりにCD使う。 3).スマイルボタンに登録したプログラムでカレントプロジェクト参照したい場合、CLIPBOARD()で取得する。 こう書いてみるとやっぱり面倒くさいね。TOP MENUからプロジェクト変更したらダメだろうし。

＃やっぱり見当違いだった^^; COMMON DEFにしたからってグローバル変数の値維持できませんね。おっしゃる通りプログラム実行した時点でグローバル変数初期化されますし。 試しててちょっと解ってきました。 DirectモードってSLOT0と考えれば良いみたいですね。 ＃だからCOMMON DEFにしたらSLOT3でも ＃動いたんだな。動きはしたけどDirectモードで ＃?CRNTPRJ$としてもSLOT0からSLOT3の ＃グローバル変数の参照になるので見えないと。 やはり現状の仕様でカレントプロジェクト問題何とかするには、自分の環境限定にはなってしまうけどCLIPBOARD使うってのも良さそうですね。あと、KEYも思い付いた(どっちでも一緒か)。 ＃自分の環境限定というのは、それ前提で ＃プログラム作ったら、公開しても他の環境では ＃動かないという意味です。

PRGSLOT適当なこと言っちゃってすみません。 ＃しかしためになるなぁ3号コミュ。感謝)^o^( グローバル変数スロット間で受け渡せるというのは、SLOT3でもCOMMOM DEFにしたら動いたことが、そういうことになるのかなぁ?(また見当違いなこと言ってるかも知れません。後でちゃんと調べてみます)

＃説明って難しい^^; 先に示してたプログラムは、これで解決してやろう、っていう本命ではなくて、PROJECT命令の仕様案を、思い付きでプログラムで書いてみたものでした。

CLIPBOARDって手もありましたね。 ＞グローバル変数もスロットによって異なる というのは勉強不足でよく分かってませんm(__)m それも含めてこの手のこと(プロジェクトとかスロットとかユーザ関数を別スロットで使うとかDirectモードで使うとか)は最近になって気になり出して、只今勉強中です。 先のプログラムはPROJECT命令がシステム変数扱ったらこんな感じかなっていう思い付きで、やっぱりプログラムスロット消費しちゃう時点で嬉しくないんですよね^^; ＃そしてちょっと試したら、スロット0なら動くけど ＃スロット3ならエラーで、COMMON付けたら ＃スロット3でも動くのか、とかを今更確認してる ＃くらいの知識レベルです。私^^; なんか上手い仕様でSmileBoomさん正式対応してくれないかなぁ。

MIKIさん＞ そういう関数あれば解決ですね(^o^) 私が思い付いたアイデアは、カレントプロジェクトのシステム変数CRNTPRJ$(例えばね)を用意して、PROJECT命令でカレントプロジェクトを変更した時はCRNTPRJ$も変更される、です。 で、下記プログラム思い付いたんだけど VAR CRNTPRJ$ DEF CD PJ$ PROJECT PJ$ PROJECT OUT CRNTPRJ$ END プチコン起動したら毎回最初にこのプログラム実行するようにして、以後PROJECTの代わりにCDと打つようにする。う～ん、苦しいな^^;やっぱり正式対応して欲しい。 ＃今気付いたけどプログラム中にPROJECT ＃書けてるねぇ^^;DEFでDirect実行なら良いのか? でんぺんさん＞ システム変数PRGSLOTって使えないのかな? (すみません未確認)

マギーさん＞ ふむふむ、今の仕様が自然という考えもあるんですね。興味深いです。 ZEXさん＞ おぉ、過去仕様変更されたことあったんですね。であれば、やはり今の仕様にした理由が何かあるということか(これはもう、サポートに問い合わせてみようかしら)。 私もEXECと別SLOT利用で回避できないか色々考えましたが、結局解決には至りませんでした。 ＃過去ログ漁ってみます。

思慮不足ってのはSmileBoomさんに対して失礼だったかも知れませんね。よくよく考えた末の今の仕様かもしれないし。 ＃むしろ何も考えず「作業中のプロジェクトが ＃常にカレント」って思ってた私、浅はかか^^; あぁ～気になるなぁ、今の仕様になった理由。

＃おっとプレッシャー^^; 私が今の仕様を知る前に勝手に思い込んでいたのは、カレントプロジェクトは常にDirectモードで見えている、作業中のプロジェクトがカレント。です。 仮にスマイルボタンで起動したプログラムにLOAD "GRP4:DEFSP.GRP"とあって、そのファイルの無いプロジェクトで実行してファイル無いよエラーになったとしても、それはファイルの無いプロジェクトで実行した私、もしくはそのプログラムにプロジェクト名を含めて記述していなかった私が悪い。と考えます。 「いやいやそんなんじゃこんなとき困るじゃん」とかあればご指摘頂きたいところです。

＃ためになる情報盛りだくさんで鼻血出そう^^; ＃さすが3号コミュ。SLOT4。まるで裏技^^; 前からこういう仕様だったんですねorz 改善の見込み薄だなぁ。互換性問題出るだろうし。 ＃私は初期仕様検討の思慮不足だと考えてます。 例えばプロジェクト"PJ1"のプログラム"PR1"(内容:SAVE "TXT:T1")をSLOT1にロードして、プロジェクト"PJ2"でRUN 1すると、当然"PJ2"にT1セーブされますよね。それがSLOT4だとしても"PJ1"にセーブされていい訳がない。と考えます。 ＃これを私は妥当とは言いたくない。 ＃言いたくないんだけどなぁ。今更かぁ。。。 多分今までの歴史?の中でも議論あったんでしょうね。 まぁ、FILES "//"とかで何とかやりくりしようと思います(CHKCHRは何だか歯がゆいね^^;)。

BIGしか持ってなくて恐縮ですがおじゃまします。 スマイルボタンで起動した時のカレントプロジェクトについて確認させて下さい。 BIGではそのプログラムを置いてるプロジェクトがカレントプロジェクトになるようですが、3号でも同様でしょうか? 同様の場合、それは以前のバージョンから変わらずでしょうか? 背景: お絵かきツール(SBGED)を改造して、新たに作った"SYS_S1"プロジェクトに置いて使ってるのですが、絵のセーブ場所が必ず"SYS_S1"になってしまうのが不便だと思ってます。因みに[SYS]のツールだと作業中のプロジェクトにセーブされます。 ご教授よろしくお願いします。

私はBIGしか持ってないのでBIGで頑張るしかないのですが、3号の方の熟成度というか充実ぶりはスゴそうですね。 という訳で、ちょっとがんばってキー割り当ての変更機能を追加してみました。 公開キー:5RWE5VQE あと、TABオンの意味を逆(オンで文字入力のみ)にしてみました(その方がキーボード使いには便利かなと思いまして)。UTIL.CFGで指定できるようになってます。従来操作が良い場合は起動時のTABモードをオンにしておけば違和感ないかと思います。 ＞なかくんさんへ もし気に入りましたら採用して頂けたら幸いです。 気に入らなかったらスルーしちゃって下さい。 ＃こんなことしてるうちにINKEY$改善されたり ＃とか。それはそれでハッピーだけど。 ＃この前はSBGED改造して直ぐに正式更新された。

良く考えてみればそうですよね^^; ＃昨日布団に入ってから「勘違いしてるっ!」って ＃気付いたんだけどそのまま寝ちゃいました。 早くINKEY$改善されないかなぁ。そうすればかなり可能性広がるのになぁ。 ＃キーボード版のBUTTON関数みたいなのも欲しい

これは良いものを教えていただきました(^o^) さっそく使ってます。 これはなかくんさんへのコメントになりますが、USBキーボード用にTABモードを備えてますが、TABオンにすると文章が入力できなくなります(カーソル移動や文節変更とかはできる)。多分意図した動作ではないと思いましたので(TABオンはカーソル移動とかに割り当てたキーだけ文章入力に使えなくなるというのが狙いかと)コメントさせていただきました。 ＃USBキーボード用にキー割り当て変更可能に ＃しようとしてて気付いた次第です。

いろいろ試してみました。 RUNで実行した場合： 　SAVE、EXEC共に、PROJECT指定NG(エラー) スマイルボタンで実行した場合： 　PROJECT指定はOK。但しPROJECT OUTで 　得られるカレントプロジェクトはプログラムの 　置いてあるプロジェクト。 こんな仕様なのか．．． やっぱりカレントプロジェクトは作業中のDirect モードで見えてるプロジェクトじゃないと不便だと思うんだけどなぁ。何か私の思い付いてない不都合があるのかなぁ。にしても[SYS]なら作業中のプロジェクトにSAVEできるし。 ＃こんな仕様やだなぁ(-_-;)

BIGの方ではどうでしょう? 最初PROJECT OUT使わずにSAVEしてました(それでも勝手にDirectモードのプロジェクトがカレントになるものだと思って)が、PROJECT OUTでプロジェクト名取得して、それをファイル名に足してもダメでした(添付画像の反転してるところ)。 今はスマイルボタン→SBSMILE→SBGEDと実行してる状況なので、もうちょっと状況単純にしていろいろ試してみようと思ってます。

以前作ったキーボードを鍵盤にするやつに、MMLの記憶機能その他を追加して、お気楽作曲ツールに仕上げてみました。 公開キー：ZKE45N8E 相変わらずキーリピートのせいでもっさりしてますが、メロディーラインをさくっと作るのには便利かも。 使い方： 　A/Qで音色選択。!で記憶する・しない。 　BackSpaceでクリア。TABでMML退避。 　Enterで再生。Escで終了(クリップボードに保存) 録音しっぱなしでも休符を記憶し続けるなんてことはないので、常に録音中で良いかも(もちろん物音立てないようにする必要なし^^;)。黄色いMML文字は記憶されてますが、BackSpaceで消せるので、気楽に何度も弾き直せます。上手く弾けた時TABで退避すれば、BackSpaceで消えないところに残せます。Escで終了時に、それまで記憶したMMLをクリップボードに格納します。

いざなわれて3号の方覗いてみたら、高度な話題が展開されてましたねぇ(今となってはC言語の方がなんだか懐かしい^^;)。 結局のところ、文字数1の文字列の配列?はメモリ効率が悪く、8の倍数文字だと効率良さそう?(ざっくりし過ぎ?)

そっか、複数トラックあって、しかも既にMML大分打ち込んじゃってると、後からDATAに手を加えるの面倒かもしれませんね。残念ながらDATAそのままでBGM~命令とかで何とかするのは無理そう。 もう手遅れかも知れませんが、MMLのDATA(文字列)を、ある程度種類毎に分類しておけば、調整(デバッグ)楽だったと思います。 例えば最初の設定は 　HEAD$="@0T120O4" 各トラック、イントロ、Aメロ、Bメロなど 　INTROT1$=".....":INTROT2$="..... 　AMEROT1$="..... 　BMEROT1$="..... 　..... 再生は BGMPLAY HEAD$+INTROT1$+AMEROT1$+... Aメロだけ再生なら BGMPLAY HEAD$+AMEROT1$+AMEROT2$+... みたいな。

スマイルボタンで起動したツールでのSAVE場所