Jump to content


Photo

New Tool (3.0,3.1): xStream

live coding sandbox

  • Please log in to reply
218 replies to this topic

#176 g8tr1522

g8tr1522

    Member

  • Normal Members
  • PipPip
  • 32 posts
  • Gender:Male
  • Location:Gainesville, FL

Posted 19 November 2017 - 18:29

Basically, that xStream is such a large tool that some internal limitations/restrictions in lua are starting to apply.

Whoah, no way! That's nuts. 
 

Still not sure exactly what triggers the problem, but, hm, I do know of a workaround: removing key shortcut /midi mappings from the main.lua file. 
At least, that has worked until now and hopefully, will be enough until we can solve this issue properly (as in: compile the built-in lua component with the ability to load more resources)

 

just to be absolutely sure, this is what you mean?

Spoiler

 

...Which I just did, and it worked! This will be totally fine for me, since I'm not using midi or keyboard mappings right now. 

 

But that is "scary" as others mentioned on page 5. Is this issue with the lua compiler just in Renoise? Or is this with lua in general? (doubt it). Hopefully this can be an easy fix. I'm just afraid that the multi-track update will 'take up more resources', leaving me with less to room to include my own stuff.  :o

 

Wish I could pitch in somehow too, with the code. This is definitely becoming my 'best girl' for making music, lol. Is there a donate link for xStream??


Edited by g8tr1522, 08 January 2018 - 20:05.


#177 danoise

danoise

    Probably More God or Borg Than Human Member

  • Renoise Team
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 7008 posts
  • Gender:Male
  • Location:Berlin
  • Interests:wildlife + urban trekking

Posted 19 November 2017 - 19:54

Yeah, there's some cool nerd-factor to hitting this ceiling (xStream == extreme), but that doesn't really comfort me. 

Problem is, the reason is still unknown. I've done a bit of research on the topic, but not much has come up. 

 

Is this issue with the lua compiler just in Renoise? Or is this with lua in general? (doubt it). 

 

Well, all these runtimes would be compiled to some setting or the other. I think our settings are even a bit less restrictive than most. 

But it's true that it makes it a little more daunting to "just add stuff on top" when you know that, somewhere, something might break.


Tracking with Stuff. API wishlist | Soundcloud


#178 joule

joule

    Guruh Motha Fakka is Levitating and Knows Everything About Renoise Member

  • Normal Members
  • PipPipPipPipPipPipPipPipPipPipPipPipPip
  • 1862 posts
  • Gender:Not Telling

Posted 20 November 2017 - 11:16

I have a request/idea.. maybe it could be called xLight :blink:

The idea is that xStream could be stripped of many things (including most of its gui and midi handling), for the purpose of only using the generative/sandbox part as easily accessible presets.

A simple user case example:
1) Right click the pattern editor.
2) Navigate to context menu "xLight presets:"
3) Select stuff like "Pad every 4th line with C-4 and the currently selected insrument" (but with shorter names). Or "Transform chords to Axx arps" et c

These presets would be the same as xStream sandbox code, and could potentially operate on either patterntrack or track in song or selection.

The clever thing with the xStream framework in this case is that its presets can act as either purely generative models, or "filters" that you parse your already tracked data thru. Both scenarios very useful - and with presets accessible by only a few mouseclicks in the pattern editor context menu.

I don't imagine that this would "compete" with xStream, but rather make more users intrigued by it.

(details: I imagine that it would also be good to have some requester callback accessible from the sandbox, to prompt the user for simple input values when needed)



#179 danoise

danoise

    Probably More God or Borg Than Human Member

  • Renoise Team
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 7008 posts
  • Gender:Male
  • Location:Berlin
  • Interests:wildlife + urban trekking

Posted 20 November 2017 - 13:18

I have a request/idea.. maybe it could be called xLight :blink:

 

And it should work with pattern aliases too?   ^_^

Hehe.

But seriously, I'm open to that idea. Live streaming is a special focus of xStream, and granted, that's not everybody's cup of tea. 


Tracking with Stuff. API wishlist | Soundcloud


#180 joule

joule

    Guruh Motha Fakka is Levitating and Knows Everything About Renoise Member

  • Normal Members
  • PipPipPipPipPipPipPipPipPipPipPipPipPip
  • 1862 posts
  • Gender:Not Telling

Posted 20 November 2017 - 14:25

Pattern aliases aren't a problem as it wouldn't be realtime or streaming, but just one-shot like the render buttons in current xStream.

 

It shouldn't be difficult to list the presets in a context menu - and then load+trigger xstream.process:fill_track() or fill_selection() ?

 

A small tick box in the model could state if it should be listed in the pattern editor menu. This would be for the more "simpler" models that don't require a GUI - or perhaps just a single user value as input. Maybe the tick box would state if the full-blown xStream GUI will be brought up on menu selection or not. These models would then be listed with "..." appended in the menu.

 

This should be rather simple to do, I imagine? Maybe just a matter of avoiding ui:show() + building the proper menus.


Edited by joule, 20 November 2017 - 14:28.


#181 g8tr1522

g8tr1522

    Member

  • Normal Members
  • PipPip
  • 32 posts
  • Gender:Male
  • Location:Gainesville, FL

Posted 11 December 2017 - 09:29

Just a couple of quick things. Feature requests actually. :)

 

table.unpack isn't usable in an xStream model.

I'm wanting to use it in my library, but I'm having to resort to making my own version of it. 

 

Could there be a button that toggles the console messages for syntax errors?

Or maybe press a button to get the most recent error message. I just hate how there's a bunch of useless error messages every time I type out a new, valid statement.

 

In other news, my hacky way of adding my code to xStream is coming along smoothly-ish. I have the whole thing required in one file, which I only need a single require for in main.lua. Then I avoid the weird error from requiring more than one file. So now I can keep MIDI and key mappings! Haven't tried them out yet though.


Edited by g8tr1522, 11 December 2017 - 09:31.

  • danoise likes this

#182 danoise

danoise

    Probably More God or Borg Than Human Member

  • Renoise Team
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 7008 posts
  • Gender:Male
  • Location:Berlin
  • Interests:wildlife + urban trekking

Posted 11 December 2017 - 14:06

table.unpack isn't usable in an xStream model.

 

AFAIK, unpack isn't available as a method of the table. Have you tried using just unpack  ? 

 

And I know that the error logging is a bit excessive. It's nice to have, but most of the time it's just adding noise. 

I'll look closer at, with regard to the whole "external editing" workflow. Ideally, I would like to use the scripting console or something like Sublime to edit the source. 


Tracking with Stuff. API wishlist | Soundcloud


#183 g8tr1522

g8tr1522

    Member

  • Normal Members
  • PipPip
  • 32 posts
  • Gender:Male
  • Location:Gainesville, FL

Posted 11 December 2017 - 20:45

Yep! unpack works! Thanks. 

But table.unpack is vanilla lua, so I was just trying to use that.

 

Yeah, I was thinking that the "noisy" error messages would be done away with if using an external editor.



#184 joule

joule

    Guruh Motha Fakka is Levitating and Knows Everything About Renoise Member

  • Normal Members
  • PipPipPipPipPipPipPipPipPipPipPipPipPip
  • 1862 posts
  • Gender:Not Telling

Posted 13 December 2017 - 11:04

1) table.unpack is Lua 5.2, I think. Renoise uses Lua 5.1 which uses just "unpack".

2) I think you can override any custom logging from xStream by overriding the TRACE() function with something like this. Maybe there is a cleaner way, but this should work.

TRACE = function() return nil end


#185 g8tr1522

g8tr1522

    Member

  • Normal Members
  • PipPip
  • 32 posts
  • Gender:Male
  • Location:Gainesville, FL

Posted 08 January 2018 - 19:06

Hey Joule. Wasn't sure of what you meant by this:

 

 

1) table.unpack is Lua 5.2, I think. Renoise uses Lua 5.1 which uses just "unpack".

2) I think you can override any custom logging from xStream by overriding the TRACE() function with something like this. Maybe there is a cleaner way, but this should work.

TRACE = function() return nil end

 

Do you mean the TRACE function in cDebug.lua? (line 138)

 

 

And just to be clear, I only want to remove the syntax errors in an xStream model. I definitely want to keep any other error messages, since I'm constantly adding new stuff to the xStream source files.

 

Also, I had no idea Renoise used Lua 5.1. Which is definitely troubling, since I've been testing all my code outside of Renoise with Lua 5.3....  :rolleyes:


Edited by g8tr1522, 08 January 2018 - 21:40.


#186 g8tr1522

g8tr1522

    Member

  • Normal Members
  • PipPip
  • 32 posts
  • Gender:Male
  • Location:Gainesville, FL

Posted 08 January 2018 - 20:05

So I've been running into another problem. 

 

When I hit the play button, it seems as though I can't access line 0 in the pattern editor. Or at least not until the playback reaches the end of the current pattern and then hits pattern line 0 on the next pattern.

 

============================================================

So, I actually can access line 0. Sort of. Just not with xpos.

 

Let's say this is my xStream model:

 

    print("pattern, line = ", xpos.sequence, xpos.line)
    xline.note_columns[1].note_value = NOTE_OFF_VALUE
 
And let's say the pattern editor 'cursor' is at line 16. Hitting the play button and stopping after a bit puts an "OFF" note value on:
 - pattern line 16,
 - and on pattern lines 1 through <whatever line the cursor was at when I hit stop>.
 
But my console output is this:
    pattern, line =   1  17
    pattern, line =   1  2
    pattern, line =   1  3
    pattern, line =   1  4
    ...
 
In short, xpos.line never returns '1', at least not until the playback reaches a new pattern (and reaches pattern line 0).
But xStream does do its work on pattern line 0 (it does print an "OFF").
 

============================================================

Even worse is when I hit the record button, and then the play button.
 
Then, I don't even get an "OFF" note value on pattern line 0. Only on pattern lines 1 through ...
My console output is this:
    pattern, line =   1  2
    pattern, line =   1  3
    pattern, line =   1  4
    ...
 
 
============================================================
 
Basically, I can't get xpos.line to return 1 (corresponding to pattern line 0) until I reach a new pattern (and the playback rolls over pattern line 0).
 
Is this intended? It seems like an inconvenience if it is.
 
============================================================
I'm wondering because I'm using an if block to execute code only once at the beginning of playback. I mentioned this in an earlier post: 
Spoiler
 
I'm using this technique to instantiate objects. But I can't access the objects on pattern line 0 since the if block won't run until xpos.line returns 1.
 
That is, when my if block looks like this:
if (xpos.line==latch2nil()) then
  print("I'm only here once :(")
end
and assuming that latch2nil would return 1 the first time it's called. 
 
 
I'm gonna look into the model user-data stuff. All I'm really wanting is to have an object be persistent throughout playback/recording from xStream. This latch2nil stuff is really hacky, and doesn't even preserve the state of an object between playback in xStream.

Edited by g8tr1522, 08 January 2018 - 20:08.


#187 g8tr1522

g8tr1522

    Member

  • Normal Members
  • PipPip
  • 32 posts
  • Gender:Male
  • Location:Gainesville, FL

Posted 08 January 2018 - 22:21

Yeah, so I just figured out how to use the model data table like how you (Danoise) were trying to tell me earlier:

 

Ehrm, sorry, let me clarify this:
-> data is referring to data that you want to reference in your loop. You can add an initial value using the "+", or simply define them on-the-go.

 

Instead of trying to explain the concept, I would suggest you take a look at some of the models that make use of "data", such as the arpeggiator or LFO?

They both take advantage of the feature to add helper methods, are being initialized with specific values, etc. 

 

Essentially, data is just there for convenience, a way to access and define numbers/tables/functions/etc, so you can keep the main loop clean and focused.

In theory, you could define your (non-luabind) classes there too. 

 

 

Don't know why I couldn't get it working before...

 

So this is definitely a more legitimate technique for instantiating objects. Plus, you get the 'persistence' I was needing (ie, the data maintains its state between xStream playback instances).

 

It's kinda clunky though. If I wanna change something in my object, or add something new, I'll always have to reload the tool, no?

Is there any way to modify the model data table without reloading the tool?

EDIT: (see below)

What was that when you said "You can add an initial value using the '+'" ?

 

 

And now I'll take the opportunity to sneak in a feature request :

Can we get access to this model data table in a window alongside the editor window?

Or maybe there should be a mini console to add new members? or modify existing ones?  

 

====================================================

from EDIT :

So I just realized that yes, you can simply add and modify existing data members with ordinary declarations and assignments.

 

Which now leaves me with a new question:

Is there a way to 'reset' the data table to what it was when the tool was initially loaded?

 

Let's say I put in the model's lua file: 

    data = {
      ["val"] = " return 0 ",
    },
 
In my xStream model (the callback), I have this:
    if xinc==10 then
      data.val = 1
      data.new = "hi"
    end
 
Is there a way to "reset" the data table so that I can go back to the initial state?
(ie, data.new gets erased, and data.val becomes 0 again)
Because hitting the play button would just maintain any new additions.
 
The only way I know how is to just reload the tool. 
I suppose I could write a reset function as a member of the data table. But I can't think of how to do this generically. It would have to be specific to every xStream model. 

Edited by g8tr1522, 08 January 2018 - 22:59.


#188 danoise

danoise

    Probably More God or Borg Than Human Member

  • Renoise Team
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 7008 posts
  • Gender:Male
  • Location:Berlin
  • Interests:wildlife + urban trekking

Posted 09 January 2018 - 10:44

When I have some time I'll look into the "accessing first line" issue.

Thanks for the details!

 

Is there a way to "reset" the data table so that I can go back to the initial state?

(ie, data.new gets erased, and data.val becomes 0 again)

 

Yes, good idea. 

I would want to do it via the GUI somehow (reset, like a refresh but without reloading), but also programmatically.


Tracking with Stuff. API wishlist | Soundcloud


#189 g8tr1522

g8tr1522

    Member

  • Normal Members
  • PipPip
  • 32 posts
  • Gender:Male
  • Location:Gainesville, FL

Posted 10 January 2018 - 23:14

Okay, one of my little projects is more or less ready for early viewing.

https://github.com/g...serlib-with-LAM

It has two things I'd like you all to see (see below).

 

Use the branch "BRANCH-userlib-with-LAM" and replace your version of xStream with that.

 

It uses a git submodule, so you'll need to run appropriate git commands to get the LuaArrayMethods package loaded.

I think git submodule init --remote LuaArrayMethods will do it? Or maybe git submodule update --remote LuaArrayMethods. I literally learned git just before making this, so fair warning.

 

========================================================

So first thing I 'did' is my hacky way of adding libraries/packages to xStream.

This is more or less my "xStream-fork-thing" repo.

 

I made a 'userlib' module (kept in "source/userlib/userlib.lua"). This single module is required in main.lua. But your packages are required as members of the userlib module. I have an example package to demonstrate. 

 

To make your package visible to an xStream model, you must add an appropriate member to the props_table in xStreamModel.lua. 

 

You can get a vanilla userlib under the branch "BRANCH-userlib-vanilla".

 

========================================================

The other thing is my very handy LuaArrayMethods package. 
(master branch is always stable)
 
This makes array manipulation wayyy easier. At least in xStream. It's documentation is still really lacking, but I do have a basic tutorial in its README. 
 
There is also an xStream model (in my xStream fork) which demonstrates some basic uses of it. It's titled "~LAM - demo".
 
========================================================
 
This leaves me with a few questions:
 
Where should I host the discussion of my xStream fork? Should it be here on this thread?
 
Where should I make a discussion for my LuaArrayMethods package? I made it primarily for Renoise, but I'm not sure if it's appropriate to open up a thread for it on these forums.
 
and
Is my hacky 'userlib' technique viable for future xStream releases? I'm sure there's a lot that can be improved upon it before I make a formal pull request. But do you think it could eventually be a legitimate feature?
 
 
 
Also, many apologies for any sloppiness in my code. I'm not a programmer by profession; if it makes music, then it works for me.

Edited by g8tr1522, 10 January 2018 - 23:23.


#190 pat

pat

    Big Masta Member

  • Normal Members
  • PipPipPipPipPipPipPipPipPip
  • 515 posts
  • Gender:Male

Posted 12 January 2018 - 21:46

I can't get xStream to run on Renoise 3.1.1 on OS X 10.10.5, whether I use the published 1.57 version or the master branch from git (currently at 19d4fecc41c34796b7389c364b1c99239ee17999)

 

I get this error when installing V1.57

'/Users/padillac/Library/Preferences/Renoise/V3.1.1/Scripts/Tools/com.renoise.xStream.xrnx/main.lua' failed in one of its notifiers.
The notifier will be disabled to prevent further errors.

Please contact the author (danoise [bjorn.nesby@gmail.com]) for assistance...

main.lua:155: attempt to index field 'preferences' (a nil value)
stack traceback:
  main.lua:155: in function <main.lua:153>

and then trying to run Tools->xStream I get

'/Users/padillac/Library/Preferences/Renoise/V3.1.1/Scripts/Tools/com.renoise.xStream.xrnx/' failed to execute in one of its menu entry functions.

Please contact the author (danoise [bjorn.nesby@gmail.com]) for assistance...

./source/xStream.lua:42: attempt to index field 'prefs' (a nil value)
stack traceback:
  ./source/xStream.lua:42: in function <./source/xStream.lua:28>
  [C]: in function 'xStream'
  main.lua:116: in function 'show'
  main.lua:142: in function <main.lua:141>

I cloned the repo from git and sym-linked xStream into the tools directory, and I get this error when launching Renoise:

'/Users/padillac/Library/Preferences/Renoise/V3.1.1/Scripts/Tools/com.renoise.xStream.xrnx/' failed to load.

Please remove this tool or contact the author (danoise [bjorn.nesby@gmail.com]) for assistance...

main.lua:27: module 'source/cLib/classes/cLib' not found:
  no field package.preload['source/cLib/classes/cLib']
  no file './source/cLib/classes/cLib.lua'
  no file '/usr/local/share/lua/5.1/source/cLib/classes/cLib.lua'
  no file '/usr/local/share/lua/5.1/source/cLib/classes/cLib/init.lua'
  no file '/usr/local/lib/lua/5.1/source/cLib/classes/cLib.lua'
  no file '/usr/local/lib/lua/5.1/source/cLib/classes/cLib/init.lua'
  no file '/Users/padillac/Library/Preferences/Renoise/V3.1.1/Scripts/Libraries/source/cLib/classes/cLib.lua'
  no file '/Applications/Renoise.app/Contents/Resources/Scripts/Libraries/source/cLib/classes/cLib.lua'
  no file './source/cLib/classes/cLib.so'
  no file '/usr/local/lib/lua/5.1/source/cLib/classes/cLib.so'
  no file '/usr/local/lib/lua/5.1/loadall.so'
  no file '/Users/padillac/Library/Preferences/Renoise/V3.1.1/Scripts/Libraries/source/cLib/classes/cLib.so'
  no file '/Applications/Renoise.app/Contents/Resources/Scripts/Libraries/source/cLib/classes/cLib.so'
  no file '/Users/padillac/Library/Preferences/Renoise/V3.1.1/Scripts/Libraries/source/cLib/classes/cLib.dylib'
  no file '/Applications/Renoise.app/Contents/Resources/Scripts/Libraries/source/cLib/classes/cLib.dylib'
stack traceback:
  [C]: in function 'require'
  main.lua:27: in main chunk


#191 danoise

danoise

    Probably More God or Borg Than Human Member

  • Renoise Team
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 7008 posts
  • Gender:Male
  • Location:Berlin
  • Interests:wildlife + urban trekking

Posted 12 January 2018 - 21:55

Hi Pat!
Good to see you around. Last time you last popped in to say hi to xStream you left quite a lot of good feedback...

 

I get this error when installing V1.57

You've encountered the same issue as so many others. The problem is known and has been "fixed" (worked around)
https://github.com/r...xrnx/issues/102

 

So yeah, solution is to clone from git. But I recently switched to submodules instead of symlinking, and need to update the README (installation instructions)

I'll look into straight away..

Edit: yep, as I suspected I hadn't added submodules for xStream. Done now. 

 

To include the submodules when cloning, you need to pass the --recursive argument

git clone --recursive https://github.com/renoise/xrnx.git

 

Hope this helps!

 


Tracking with Stuff. API wishlist | Soundcloud


#192 pat

pat

    Big Masta Member

  • Normal Members
  • PipPipPipPipPipPipPipPipPip
  • 515 posts
  • Gender:Male

Posted 12 January 2018 - 22:16

Hi Pat!
Good to see you around. Last time you last popped in to say hi to xStream you left quite a lot of good feedback...

 


You've encountered the same issue as so many others. The problem is known and has been "fixed" (worked around)
https://github.com/r...xrnx/issues/102

 

So yeah, solution is to clone from git. But I recently switched to submodules instead of symlinking, and need to update the README (installation instructions)

 

I'll look into straight away..

 

 

hrm okay. I didn't see the submodule stuff. I was hoping that would be an easy fix... I did

git submodule init && git submodule update

from the main xrnx folder and that seemed to work, it cloned a bunch of submodules.

 

But I still get the third error message I showed above there, the one about cLib. For some reason (that I don't understand) the xStream submodules aren't getting pulled. Here's what I get when I init:

Submodule 'Tools/com.renoise.Duplex.xrnx/cLib' (https://github.com/renoise/cLib) registered for path 'Tools/com.renoise.Duplex.xrnx/cLib'
Submodule 'Tools/com.renoise.Duplex.xrnx/xLib' (https://github.com/renoise/xLib) registered for path 'Tools/com.renoise.Duplex.xrnx/xLib'
Submodule 'Tools/com.renoise.MidiPerformer.xrnx/source/cLib' (https://github.com/renoise/cLib) registered for path 'Tools/com.renoise.MidiPerformer.xrnx/source/cLib'
Submodule 'Tools/com.renoise.MidiPerformer.xrnx/source/vLib' (https://github.com/renoise/vLib) registered for path 'Tools/com.renoise.MidiPerformer.xrnx/source/vLib'
Submodule 'Tools/com.renoise.MidiPerformer.xrnx/source/xLib' (https://github.com/renoise/xLib) registered for path 'Tools/com.renoise.MidiPerformer.xrnx/source/xLib'
Submodule 'Tools/com.renoise.Noodletrap.xrnx/classes/cLib' (https://github.com/renoise/cLib) registered for path 'Tools/com.renoise.Noodletrap.xrnx/classes/cLib'
Submodule 'Tools/com.renoise.Noodletrap.xrnx/classes/xLib' (https://github.com/renoise/xLib) registered for path 'Tools/com.renoise.Noodletrap.xrnx/classes/xLib'
Submodule 'Tools/com.renoise.PhraseMate.xrnx/source/cLib' (https://github.com/renoise/cLib) registered for path 'Tools/com.renoise.PhraseMate.xrnx/source/cLib'
Submodule 'Tools/com.renoise.PhraseMate.xrnx/source/vLib' (https://github.com/renoise/vLib) registered for path 'Tools/com.renoise.PhraseMate.xrnx/source/vLib'
Submodule 'Tools/com.renoise.PhraseMate.xrnx/source/xLib' (https://github.com/renoise/xLib) registered for path 'Tools/com.renoise.PhraseMate.xrnx/source/xLib'
Submodule 'Tools/com.renoise.ScaleMate.xrnx/source/cLib' (https://github.com/renoise/cLib) registered for path 'Tools/com.renoise.ScaleMate.xrnx/source/cLib'
Submodule 'Tools/com.renoise.ScaleMate.xrnx/source/xLib' (https://github.com/renoise/xLib) registered for path 'Tools/com.renoise.ScaleMate.xrnx/source/xLib'
Submodule 'Tools/com.renoise.SliceMate.xrnx/source/cLib' (https://github.com/renoise/cLib) registered for path 'Tools/com.renoise.SliceMate.xrnx/source/cLib'
Submodule 'Tools/com.renoise.SliceMate.xrnx/source/vLib' (https://github.com/renoise/vLib) registered for path 'Tools/com.renoise.SliceMate.xrnx/source/vLib'
Submodule 'Tools/com.renoise.SliceMate.xrnx/source/xLib' (https://github.com/renoise/xLib) registered for path 'Tools/com.renoise.SliceMate.xrnx/source/xLib'
Submodule 'Tools/com.renoise.VoiceRunner.xrnx/source/cLib' (https://github.com/renoise/cLib) registered for path 'Tools/com.renoise.VoiceRunner.xrnx/source/cLib'
Submodule 'Tools/com.renoise.VoiceRunner.xrnx/source/vLib' (https://github.com/renoise/vLib) registered for path 'Tools/com.renoise.VoiceRunner.xrnx/source/vLib'
Submodule 'Tools/com.renoise.VoiceRunner.xrnx/source/xLib' (https://github.com/renoise/xLib) registered for path 'Tools/com.renoise.VoiceRunner.xrnx/source/xLib'
Submodule 'Tools/com.renoise.cLib.xrnx/source/vLib' (https://github.com/renoise/vLib) registered for path 'Tools/com.renoise.cLib.xrnx/source/vLib'
Submodule 'Tools/com.renoise.vLib.xrnx/source/cLib' (https://github.com/renoise/cLib) registered for path 'Tools/com.renoise.vLib.xrnx/source/cLib'
Submodule 'Tools/com.renoise.vLibBoilerPlate.xrnx/source/cLib' (https://github.com/renoise/cLib) registered for path 'Tools/com.renoise.vLibBoilerPlate.xrnx/source/cLib'
Submodule 'Tools/com.renoise.vLibBoilerPlate.xrnx/source/vLib' (https://github.com/renoise/vLib) registered for path 'Tools/com.renoise.vLibBoilerPlate.xrnx/source/vLib'
Submodule 'Tools/com.renoise.xCleaner.xrnx/source/cLib' (https://github.com/renoise/cLib) registered for path 'Tools/com.renoise.xCleaner.xrnx/source/cLib'
Submodule 'Tools/com.renoise.xCleaner.xrnx/source/vLib' (https://github.com/renoise/vLib) registered for path 'Tools/com.renoise.xCleaner.xrnx/source/vLib'
Submodule 'Tools/com.renoise.xCleaner.xrnx/source/xLib' (https://github.com/renoise/xLib) registered for path 'Tools/com.renoise.xCleaner.xrnx/source/xLib'
Submodule 'Tools/com.renoise.xLib.xrnx/source/cLib' (https://github.com/renoise/cLib) registered for path 'Tools/com.renoise.xLib.xrnx/source/cLib'
Submodule 'Tools/com.renoise.xLib.xrnx/source/vLib' (https://github.com/renoise/vLib) registered for path 'Tools/com.renoise.xLib.xrnx/source/vLib'

So... lots of submodules, but none of the xStream ones.



#193 danoise

danoise

    Probably More God or Borg Than Human Member

  • Renoise Team
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 7008 posts
  • Gender:Male
  • Location:Berlin
  • Interests:wildlife + urban trekking

Posted 12 January 2018 - 22:22

Oh, look above. For whatever reason, I hadn't added xLib etc. to the xStream tool. 

 

Looking forward to your input - since last time, I've fixed some annoying bugs and reworked the streaming to make it a lot faster. 


  • pat likes this

Tracking with Stuff. API wishlist | Soundcloud


#194 pat

pat

    Big Masta Member

  • Normal Members
  • PipPipPipPipPipPipPipPipPip
  • 515 posts
  • Gender:Male

Posted 12 January 2018 - 22:29

okay thanks! btw I thought I was going crazy... I wiped the dir, cloned to get a clean repo, and it didn't work. I wiped the dir again, cloned again, and it worked this time – I hadn't realize that you had fixed it in between the times I had cloned it! :)



#195 pat

pat

    Big Masta Member

  • Normal Members
  • PipPipPipPipPipPipPipPipPip
  • 515 posts
  • Gender:Male

Posted 13 January 2018 - 01:40

Okay I'm up and running, checked out some stuff and it's cool – I'm getting the hang of xStream models again.

 

(btw I had stayed away from xStream for a while because I'm more interested in it for offline work for the time being, and it didn't really support that workflow for a while. Anyway...)

 

The challenge I'm running into right now is that the model I'm working on is somewhat complex, and for me to have a chance at completing it I need to take a more structured approach to it – at the very least, write tests so that I know I have my basic examples working. Splitting things into separate files and editing with a text editor would be sweet too.

 

Do you have any suggestions for how to go about constructing a library outside of xStream that I can use inside it? I saw this post which looks like it aims to do something like that.

 

It may be that my idea (a voice leading tool, which joule did say would be challenging...) is too big for an xStream model and is better off as its own tool. But I really like the xStream approach, configuration with args etc. What do you think?



#196 joule

joule

    Guruh Motha Fakka is Levitating and Knows Everything About Renoise Member

  • Normal Members
  • PipPipPipPipPipPipPipPipPipPipPipPipPip
  • 1862 posts
  • Gender:Not Telling

Posted 13 January 2018 - 14:54

I just wanted to drop a very small idea regarding the GUI, before I delete it, that could perhaps inspire some further revamping. I think the xStream GUI has quite an intense scare factor to new users, with all its custom buttons and symbols.

 

xgui.gif



#197 danoise

danoise

    Probably More God or Borg Than Human Member

  • Renoise Team
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 7008 posts
  • Gender:Male
  • Location:Berlin
  • Interests:wildlife + urban trekking

Posted 13 January 2018 - 15:12

@joule: good idea. I can get confused myself  ^_^

 

Edit: btw: did you actually implement these changes? Could you perhaps share them with me (I'm lazy) 

 

It may be that my idea (a voice leading tool, which joule did say would be challenging...) is too big for an xStream model and is better off as its own tool. But I really like the xStream approach, configuration with args etc. What do you think?

 

Indeed, some things are just too big or complex to make them suitable for a model. But unless there's some major restructuring required, it would be quite simple to "knock a hole" through the xStream sandbox and provide access to your own library/class. 

 

If your class is well structured, it should be easy to port it over, make a standalone tool at a later point. Using xStream as a rapid-prototype kind of tool  ^_^

 

On a more general note, "streaming" dictates a certain kind of thinking, where you can only respond to things as they happen. 

A person (can't remember who) asked if it would be possible to sort notes using xStream. My response : not the right tool for the job, because you don't know what's going to happen at a later time. This is something I'm not planning to change. 


Edited by danoise, 13 January 2018 - 17:16.

Tracking with Stuff. API wishlist | Soundcloud


#198 g8tr1522

g8tr1522

    Member

  • Normal Members
  • PipPip
  • 32 posts
  • Gender:Male
  • Location:Gainesville, FL

Posted 14 January 2018 - 02:22

Do you have any suggestions for how to go about constructing a library outside of xStream that I can use inside it? I saw this post which looks like it aims to do something like that.

 

Hey, that's me!

 

Yeah, so I've successfully gotten my own external libraries to work in xStream.

https://github.com/g...userlib-vanilla

Initialize the repo in your tools folder in a folder named "com.renoise.<some name>.xrnx".

(I haven't set this up as a fork off of the official renoise repo yet).

Checkout the branch "BRANCH-userlib-vanilla" to get a clean slate. 

I have small instructions in "source/userlib/userlib.lua" and in "source/xStreamModel.lua".

 

I write and test my libraries' code externally before testing/using it in xStream. I haven't had many hiccups. The trick is to put everything into one module (which I called userlib), and require that module in main.lua. Otherwise, you get weird errors for requiring two or more things in main.lua. You must also make your libraries visible in "source/xStreamModel.lua". 

 

I'll also shamelessly plug my LuaArrayMethods library again. You can check that out if you checkout the branch "BRANCH-userlib-with-LAM".


Edited by g8tr1522, 14 January 2018 - 16:07.

  • danoise likes this

#199 danoise

danoise

    Probably More God or Borg Than Human Member

  • Renoise Team
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 7008 posts
  • Gender:Male
  • Location:Berlin
  • Interests:wildlife + urban trekking

Posted 15 August 2018 - 08:39

I just wanted to drop a very small idea regarding the GUI, before I delete it, that could perhaps inspire some further revamping.

 
No further revamping, but I (still) think this is a good idea.
Other than that, I'm just looking to polish off the improvements we've made, and (try to) properly test it.
  • joule likes this

Tracking with Stuff. API wishlist | Soundcloud


#200 joule

joule

    Guruh Motha Fakka is Levitating and Knows Everything About Renoise Member

  • Normal Members
  • PipPipPipPipPipPipPipPipPipPipPipPipPip
  • 1862 posts
  • Gender:Not Telling

Posted 15 August 2018 - 09:03

What news will there be since the last official version? :)

 

I've been keen on submitting some actual suggestions (gui improvements and "xlight menu") but didn't know what branch to start from.

 

EDIT:

1) Having a brief look at cLib/cSandbox. The __index metamethod looks VERY suboptimal (like table.find on every call et c). It would be better to set up an environment with allowed keys on init. And the properties scheme there is a bit extravagant with some overhead, compared to storing stuff directly in the environment table. The sandbox variables are quite 'fixed' in the xStream implementation anyway, I'd suppose.

 

This should be quite easy to optimize heavily, for a less green environment?

 

2) I made a trace function that features indentation B)  , like a virtual code tree if you put TRACE inside every function. I'll try sharing this after trying to add a (rough) function counter inside. That should be really interesting for optimizing a big tool like xStream, clearly showing what functions to focus most on. Maybe these things could be interesting for cDebug


Edited by joule, 15 August 2018 - 09:56.






Also tagged with one or more of these keywords: live coding, sandbox