1 Topic by Ampco_Raphael

  • Ampco_Raphael
  • Member
  • Offline
  • From: Ampco Belgium
  • Registered: 2008-03-15
  • Posts: 11

Topic: Feature Requests: licensing nware view file designs

Hello everybody,

Having several projects with scripts of over a few thousands lines, I'd like to have some opportunity to display license agreements.

Some thoughts:

- possibility to embed a license text in the .npa file;
- having a possibility to ask the user to accept a license when deploying a view file;
- having a possibility to display a splash window with license or copyright informations when a kiosk connects;
- an 'about' button on the kiosk that displays a splash window  when hit (that's do-able as is but I'd like to see that integrated on the kiosk title bar because it can easily be removed from the view file!);
- having a possibility to lock a script code so that it cannot be seen or edited without password;
- having a possibility to restrict the usage of a view file to a certain list of nions (depending on the serial number for example);

Regarding script development:

I'd like to have a mode where the scripts are stored outside of the viewfile. Upon selection of this mode, the scripts are copied in a folder named 'src' in the same directory as the viewfile, under 'function_name.py'. Then the scripts can easily be edited with a python editor and maintained under a versionning system. When the viewfile is compiled, the content of the 'src' folder would be merged with the .npa file, each function_name.py replacing (or creating) respective scripts.

Just suggestsions

Best regards

--
Raphaël Bollen
Ampco Belgium.

Ampco_Raphael's Website

2 Reply by JoshM

  • JoshM
  • JoshM
  • Recording Engineer at Burnt Orange Studio
  • Offline
  • From: Meridian, MS
  • Registered: 2007-08-13
  • Posts: 1,498

Re: Feature Requests: licensing nware view file designs

Hi Raphael-

These are some very interesting thoughts.

We are currently reviewing the implementation of User Devices in NWare, so your thoughts come at a very handy time.

Thank you for your suggestions! You may see some implementation of your comments in a future release of NWare.

Thanks!

-Josh

Josh Millward
Burnt Orange Studios

JoshM's Website

3 Reply by Ampco_Raphael

  • Ampco_Raphael
  • Member
  • Offline
  • From: Ampco Belgium
  • Registered: 2008-03-15
  • Posts: 11

Re: Feature Requests: licensing nware view file designs

JoshM wrote:

Hi Raphael-

These are some very interesting thoughts.

We are currently reviewing the implementation of User Devices in NWare, so your thoughts come at a very handy time.

Thank you for your suggestions! You may see some implementation of your comments in a future release of NWare.

Thanks!

-Josh

I would be delighted!

Thx

--
Raphaël Bollen
Ampco Belgium.

Ampco_Raphael's Website

4 Reply by Fergy

  • Fergy
  • MM Tech Support
  • Offline
  • From: The Home Office--Meridian
  • Registered: 2007-08-15
  • Posts: 334

Re: Feature Requests: licensing nware view file designs

Ampco_Raphael wrote:

Regarding script development:

I'd like to have a mode where the scripts are stored outside of the viewfile. Upon selection of this mode, the scripts are copied in a folder named 'src' in the same directory as the viewfile, under 'function_name.py'. Then the scripts can easily be edited with a python editor and maintained under a versionning system. When the viewfile is compiled, the content of the 'src' folder would be merged with the .npa file, each function_name.py replacing (or creating) respective scripts.

Let me start out with this information for those who are not aware.  NPA stands for Nion Project Archive, and is a “zip"  file.  You can view the contents of this file by changing the attribute from .npa to .zip.  (I always make a copy of the original file, and then change it to .zip, just in case).  You will find inside of the zip folder another folder called “targets" .  Inside target will be one or more folders, each representing the NioNodes of the Project.  When a Python Script is created in NWare, the script is contained in an xml called “pacman_python_config.xml" .

That explained, I’m not sure I agree with creating another file that is outside of the npa.  One of the great features that I love about NWare over MWare is that EVERYTHING is in a single file.  I remember the days of copying everything in the folder, making sure I had the graphics, the presets, the wavs, and all of the other details from the MainFrame to a floppy or a USB drive.  Some of you will remember having to install winzip on the MainFrame, so all of these files could be copied to a floppy.  Oh, the joy.  And it’s even more fun trying to explain how it is done on a tech support call.

But back on point, I just tested the theory of editing the above xml file when the Project file is open (this is found in “C:Users/All Users/MeidaMatrix/(version of software in use)/Temp" ), and you can’t.  None of the changes that I tried remained intact, even when I would make a change, save it to the xml, and then save the Project file (at least not with Wordpad, since I don’t have an xml editor).  Making a change to the xml after the Project is closed (by changing npa to zip, editing the xml, and the reverting back npa) would be beyond all but the very advanced programmers of NWare.

But check it out, and let us know if this is a way to do what you require.  If not, continue to explain why there is a need for an external scripting file outside the npa file.  But being able to hide and lock your scripts, that one is a very good idea!

Make it intuitive, never leave them guessing.

5 Reply by Ampco_Raphael

  • Ampco_Raphael
  • Member
  • Offline
  • From: Ampco Belgium
  • Registered: 2008-03-15
  • Posts: 11

Re: Feature Requests: licensing nware view file designs

Fergy wrote:
Ampco_Raphael wrote:

Regarding script development:

I'd like to have a mode where the scripts are stored outside of the viewfile. Upon selection of this mode, the scripts are copied in a folder named 'src' in the same directory as the viewfile, under 'function_name.py'. Then the scripts can easily be edited with a python editor and maintained under a versionning system. When the viewfile is compiled, the content of the 'src' folder would be merged with the .npa file, each function_name.py replacing (or creating) respective scripts.

Let me start out with this information for those who are not aware.  NPA stands for Nion Project Archive, and is a “zip"  file.  You can view the contents of this file by changing the attribute from .npa to .zip.  (I always make a copy of the original file, and then change it to .zip, just in case).  You will find inside of the zip folder another folder called “targets" .  Inside target will be one or more folders, each representing the NioNodes of the Project.  When a Python Script is created in NWare, the script is contained in an xml called “pacman_python_config.xml" .

That explained, I’m not sure I agree with creating another file that is outside of the npa.  One of the great features that I love about NWare over MWare is that EVERYTHING is in a single file.  I remember the days of copying everything in the folder, making sure I had the graphics, the presets, the wavs, and all of the other details from the MainFrame to a floppy or a USB drive.  Some of you will remember having to install winzip on the MainFrame, so all of these files could be copied to a floppy.  Oh, the joy.  And it’s even more fun trying to explain how it is done on a tech support call.

Hi Fergy,

I know all this about the view file and I also like to keep it only one file. But...

Fergy wrote:

But back on point, I just tested the theory of editing the above xml file when the Project file is open (this is found in “C:Users/All Users/MeidaMatrix/(version of software in use)/Temp" ), and you can’t.  None of the changes that I tried remained intact, even when I would make a change, save it to the xml, and then save the Project file (at least not with Wordpad, since I don’t have an xml editor).  Making a change to the xml after the Project is closed (by changing npa to zip, editing the xml, and the reverting back npa) would be beyond all but the very advanced programmers of NWare.

That's the problem, the script is also stored in a another file data.pdn which is a binary file and not so easily edited. I guess nware uses data.pdn to generate the pacman_python_config.xml.

Fergy wrote:

But check it out, and let us know if this is a way to do what you require.  If not, continue to explain why there is a need for an external scripting file outside the npa file.  But being able to hide and lock your scripts, that one is a very good idea!

If it was possible to extract and re-merge the scripts, that would be half the solution because you would need to restart NWare after each modifications of a script.
But if Nware provides a switch 'external script editor' similar to 'Incremental compilation' then when the switch is turned 'on' the scripts are copied in a 'src' diretory next to the .npa.
If the switch is on and compile or emulate or save is asked then the content of the 'src' folder is reloaded in the viewfile before starting the compile or save process. Then you can have
the best of both worlds, embedded scripts and external edition.

There are three main reasons why I wish to be able to extract the scripts from the view file and merge them back when compiled.
1. The embedded editor is rather basic, enough to write a few lines but not more;
     Once opened you cannot browse the viewfile; Let's say you want to edit line 500 but don't remember which input number you have to use...
     you need to close the script, jump to the viewfile page where you can find the answer, re-open the script and scroll to line 500.
     Not really convenient, with an external editor, you can even run the viewfile;
      For that reason, I also prefer an external editor rather than a sophisticated editor embedded in Nware;
      (note:  the search function of the script editor is bogus, it finds the first occurence of a search but not the next ones..)
 
2. I'm using subversion to keep versions of the viewfile while I'm developping it. But that sort of tool is not really efficient on compressed files like .npa.
    you cannot diff two versions;
    you cannot keep different versions of the script without keeping different versions of the viewfile where only scripts have changed!
    When the file is several MBs because of media embedded and each version is a copy of it... you get the picture.

3. It would be easy to develop a framework that could run scripts without running the viewfile. That would be much faster to test and debug scripts for example when implementing
    communication protocols. When you made a typo in a variable name and the compile time takes a few minutes, you end up drinking way too much cofee :-)


I hope this clears up a little bit the request. Thanks for your attention.

Best regards

--
Raphaël Bollen
Ampco Belgium.

Ampco_Raphael's Website

6 Reply by Fergy

  • Fergy
  • MM Tech Support
  • Offline
  • From: The Home Office--Meridian
  • Registered: 2007-08-15
  • Posts: 334

Re: Feature Requests: licensing nware view file designs

Ok, I'm convinced.   So lets see if this can be defined a little better.

Change the Python Script device so it works just like it does, but add an advanced feature that calls an outside file on demand, (a browse and click of a button, perhaps), as well as from the script tab.  If the script is called from an outside file, it would NOT be visible on the script tab (which would also mean that if the script is imported from the script tab, the script could be removed from the tab).  This same process could be used to export the script.

This Python Script block could be place inside a standard block that can accept audio and control nodes, so a device could be created that includes algorithms and other controls.  This means that if the block is then defined as an user device, the script is a part of the new device (which means that it doesn't need to be created in the scripting tab when brought into a new project).

Now if the script device is placed on a tab that is locked, it would be hidden from view.  But I'm afraid it might still be in clear text, somewhere in the npa file.  So as a final added feature, add a button to the advanced device properties that encrypts the Python script.  This would also stop the export of the Python script, as it would export "hash".

The final feature is one that has been asked for on the forum before, creating a way that an advance programmer can sell their "devices", but still have some control over how many installs the buyer can have of that device.  I like the embedded license idea, and that one is new (though we are using an embedded license on a USB to protect nControl, adding an embedded license for NWare devices is new).  My biggest concern is what happens if you "disappear", is the end user now going to look to MediaMatrix to make things right?

I think creating a scripting device as defined above needs to come to the top of the list.  The embedded license idea may need to wait awhile.

Anyone have any comments?

Last edited by Fergy (2009-07-31 19:44:57)

Make it intuitive, never leave them guessing.

7 Reply by Ampco_Raphael

  • Ampco_Raphael
  • Member
  • Offline
  • From: Ampco Belgium
  • Registered: 2008-03-15
  • Posts: 11

Re: Feature Requests: licensing nware view file designs

Fergy wrote:

Ok, I'm convinced.   So lets see if this can be defined a little better.

Change the Python Script device so it works just like it does, but add an advanced feature that calls an outside file on demand, (a browse and click of a button, perhaps), as well as from the script tab.  If the script is called from an outside file, it would NOT be visible on the script tab (which would also mean that if the script is imported from the script tab, the script could be removed from the tab).  This same process could be used to export the script.

This Python Script block could be place inside a standard block that can accept audio and control nodes, so a device could be created that includes algorithms and other controls.  This means that if the block is then defined as an user device, the script is a part of the new device (which means that it doesn't need to be created in the scripting tab when brought into a new project).

Now if the script device is placed on a tab that is locked, it would be hidden from view.  But I'm afraid it might still be in clear text, somewhere in the npa file.  So as a final added feature, add a button to the advanced device properties that encrypts the Python script.  This would also stop the export of the Python script, as it would export "hash".

I would sign for this... but it leaves a question: "How do you give the nion the key to decrypt the script?". Note: this also gives an opportunity to lock the script to a nion that has the key.

Fergy wrote:

The final feature is one that has been asked for on the forum before, creating a way that an advance programmer can sell their "devices", but still have some control over how many installs the buyer can have of that device.  I like the embedded license idea, and that one is new (though we are using an embedded license on a USB to protect nControl, adding an embedded license for NWare devices is new).  My biggest concern is what happens if you "disappear", is the end user now going to look to MediaMatrix to make things right?

That's a general concern regarding closed source software... Hence the importance to be able to display splash screens, licence, contact information, etc.

Fergy wrote:

I think creating a scripting device as defined above needs to come to the top of the list.  The embedded license idea may need to wait awhile.

OK, but I think that having a clear license statement is also quite important.

What is really on top of my whish list is external edition for pure practical reasons. :-)

Fergy wrote:

Anyone have any comments?

--
Raphaël Bollen
Ampco Belgium.

Ampco_Raphael's Website