Yep. xStream is currently hard-coded to the selected track. Again, this is something that would change in the planned version
(I would like to add as a sidenote: it's nice how your questions align so nicely with those plans )
How much longer until this plan comes to action? I need a multitrack xStream man!!! But seriously, I had a ton of fun with it this weekend, but was annoyed at how my bass line AND my drum sequence couldn't be auto-composed simultaneously. My crappy suggestion for a temporary solution: allow a model to 'go in the background'. Like, it maintains control over (and continues editing the pattern data of) a certain track, but it is inaccessible to the user while they have another model open. So they can't edit the first model, or mess with the arguments GUI of that model.
Then, perhaps all running models would be on a track-by-track basis. One model per track. And when I select another track, it opens up the model assigned to that one. Not a big request at all, i know.
In other problems-i've-been-running-into: How does one edit a model in the Renoise scripting console?
However, I have been toying with an idea which would enable you to edit xstream files outside Renoise. I think this is actually a much more convenient thing, because no matter how much how we tweak the text editor in Renoise, most people who are dabbling with this tool probably have a text editor that they prefer anyway. So I see no reason why xStream shouldn't benefit from that. Hell, you could even use the Renoise scripting console then, if you wanted to (I know some people do )
If I open up my model in the console, it's in that sandbox section, which is a big block comment. Thus, there's no syntax highlighting. Not much of an improvement over the tiny black and white text in the xStream console.
But this isn't even the worse issue. When I do save changes that I made in the Renoise scripting console, the current instance of xStream suddenly closes. I have to open it and my model back up to try and execute the new code. But instead of my new code being there, my model is instead a blank canvas. It's still inside the Renoise editor, but not in the xStream one. So I have to copy and paste it from the Renoise editor to the xStream one.
I've noticed this sometimes only happens if my new code has a syntax error. If it doesn't, sometimes the model won't be blank when I open it back up. I'd be more than happy to go back and figure out/report on the exact behavior of all this if you'd like.
But not a big issue. Just making you aware. I'm perfectly fine with the xStream editor in the meantime. Also weird: if I make a change in the xStream editor (and save), it does not update those changes in the Renoise editor. Haven't tried with other editors yet. I think this also had that syntax error peculiarity.
Second issue I've been having is that I get this error:
*** Error: please review the callback function - .\source/xLib/classes/xEffectColumn.lua:216: Unexpected effect number. Expected two bytes between 0-35 respectively
It prints this constantly (in the renoise console) when I run this one model I've been using. But it's updating the effect columns just fine. I can send you the model and the song. Should I zip it?
Final issue, another weird error:
*** Expected an instance of xline for output - sequence: 4 line: 46
I also get this persistently when running my models. Sometimes, I get it and no track data is written to. Not until I click and change some args (eg, click a 'choose' button, move a minislider, etc.) will it then start putting out track data. And sometimes the error then goes away. Sometimes it doesn't.
One question: Is this worth pursuing?
I want to use Ruby array methods in xStream. I was thinking I would get these methods to work in a C program by calling the Ruby method as an external function to the C program. Then, I would try to get a Lua program to call a C function, which then just calls the Ruby method. Would this be recommended in xStream? Any problems as far as performance issues?
If not, I'd like to get that working. Array manipulation is easy peesy in Sonic Pi because of all the different methods there were. I'd like that in xStream. Otherwise, I'll probably just write them myself. Would there be any performance issues if I wrote them in C and called the C functions in xStream?
Also, thanks again for this amazing tool. It's inspired me to start making music consistently. Before, I'd make something like, 3 times max a year. Now I'm pumping out another thing every other week. And they're all miles better than what I had made before.