#601

Regarding dependencies, how do people picture sharing libraries as opposed to instruments? For instance, right now I have my arc_params lib in a github repo called arc_params, with a test.lua script in the root and a lib folder inside of it containing the library.

So it’s structured like Glut, or Awake, but you would have to require arc_params/lib/arc_params to include it which is a little weird and verbose.

2 Likes
#602

I think I’ll wait until v2 is released to make any changes. Thanks for the feedback.

Surprising that Passersby, Molly and any of the existing engines would not be included in the main engines location…

Regarding dependencies: There should be a clear way spelled out for both users and developers to know how to deal with these.

4 Likes
#603

This can happen if the filesystem hasn’t been cleanly unmounted. On Linux fsck.vfat should help.

1 Like
#604

Is there a list of engines that are moving? Having never contributed to the SC side of Norns, all of my scripts depend on other’s work. Does this mean in order to run my scripts a user will need to install several other scripts?

2 Likes
#605

the 1.x to 2.0 installer will include a bunch of the most-used engines (ie @markeats, @jah, @artfwo) but there’s a path towards moving engines out of we.

despite earlier discussion, we is really only going to be used for tutorials, tests/demos, and perhaps some libs. i don’t feel the need for a “collective” github repo, since files are much easier to just upload to the forum, or to a separate repo.

re: include() we’re working out the syntax right now… suggestions welcome regarding inter-script sharing.

#606

Seems engines and their libraries should be located in a common, known folder. This cuts confusion on both human and system level.

No need to ask typical user to install multiple scripts in multiple locations. No need to run risk of multiple versions of an instrument script out in the wild, some working and some not.

I don’t have a preference for its location - only that it be locked down sooner than later. Prior to v2 being released preferable.

8 Likes
#607

I’m slightly concerned too. Users who are not git savvy will have a tough time updating or managing this.

3 Likes
#608

many, many words have been spent on this.

just a couple replies from me and then i leave it to the guy with the final word (@tehn)

monome doesn’t want to be in the position of curating a central repository of every engine made by anyone ever. that’s not a realistic plan. any other plan requires dependency management as a fact of life.

~/dust/code. it is in the SC classpath and searched recursively.

like brian says, installer ships with common engines. there are not that many of these.

users don’t need git to install scripts or engines not shipped in installer. its up to authors to provide downloads.
users do need to be able to copy things to the norns filesystem.

4 Likes
#609

In a consumer-friendly way from a USB stick like they do on Organelle?

2 Likes
#610

currently, using a friendly SFTP client like cyberduck.

upload facility within maiden is a strong possibility but i’m not the implementer and won’t promise the work.

1 Like
#611

As mentioned earlier, SC balks if it finds multiple copies of engines. And if a script author doesn’t know explicitly where to require from… ?

Engines are necessary/required for most (all?) scripts.

How about ~/dust/engines?

This would semi-isolate engines from other script-related code.

#612

if a script author doesn’t know explicitly where to require from… ?

if i install ~dust/code/passerby i don’t need to do anything but engine.name = passerby to use the engine. if i want to make a copy of the actual engine w/ modifications, i do need to rename the class.

if i want to use the paserby_engine.lua helper i can copy it freely or just leave it where it is and use include(passerby/lib/passerby_engine)

#613
FWIW TL;DR

As a general rule, if a product’s documentation isn’t complete and/or hasn’t been field tested, the product is not ready for GA.That includes documentation at all levels: website/product marketing, quick start guides and technical documentation. It’s often the last feature through the gate and the easiest to ignore “for later”. Take the time to do it right. This is one of this things that ends up eating up developer focus better spent on squashing production bugs or working on v.next, and is a significant barrier to product adoption by post-chasm early majority user communities. I am confident that this will not be the case here.

Thank you for your forbearance.

1 Like
#614

This will show up in the list of selectable scripts when a user wants to choose a script to perform.

1 Like
#615

not sure if i understand your post
but if you are seeking docs for the sftp process (to copy/transfer files)

this guide is excellent
https://monome.org/docs/norns/sftp/

1 Like
#616

I’m just opining as a product person with more scars than can be easily or pleasantly counted. Peace.

2 Likes
#617

anything in passerby/lib is filtered out in the script select menu. yes, the top-level performable script passerby.lua will show up. is that a problem? one notion floating around is to add a “favorites” section for easier navigation, which would i think be pretty easy to do.

#618

I’m sure these were among the many words on the topic internally, but IMO sftp is just as user/consumer friendly as usb transfer- if not moreso. using the guide once or twice should make it a breeze for those even completely unfamiliar with sftp, and it’s free. both methods require a computer so that shouldn’t be a barrier, and the wifi improvements in 2.0 have made this even more painless.

just my 2c on that

8 Likes
#619

If worried about dependencies and breakage, is there anything keeping an author from including a copy of the engine in their script’s data folder? That way, the author doesn’t need to include instructions like “Please also download ______ from…”. It also prevents scripts from breaking if the engine is modified at all.

EDIT: Additionally, the script’s author could edit the engine to include a needed feature without breaking other people’s scripts.

2 Likes
#620

the only thing is SC’s annoying problem with getting hung up on duplicate class names, while failing to ignore duplicate file names. (it will happily parse two different copies of Engine_Passerby.sc, but totally fail to compile unless i rename my copy of class Engine_Passerby to class Engine_ZPasserby or whatever.) but yea, if you “fork” an engine by adding a prefix, that will work just fine.

we’ve sketched out some possible solutions to this but they come with definite compromises and are tricky. (e.g., we could modify sclang to skip duplicate filenames in class compilation; we could change classpath and reboot sclang any time an engine is loaded.) we’re going to try it this way first.

there is absolutely nothing preventing multiple copies of any .lua file existing currently, though feedback on the exact syntax/behavior of lua include could be useful at this point.

i think the SC dependencies will be less of an issue in practice - everyone who runs the 2.0 update will end up with all common engines installed, and for example @carvingcode’s scripts will work with zero additional effort from the user.

3 Likes