Myriad Forum « Methods for Copying Objects »
 Welcome, Guest.
 You can read all messages, but to be able to post,
 please Login or Register.
Aug 20th, 2014, 6:41pm 
   Myriad Forum
   MyrScript Language
(Moderator: Forum Administrator)
   Methods for Copying Objects
« Previous topic | Next topic »
Pages: 1 2  Reply | Notify of replies | Print
   Author  Topic: Methods for Copying Objects  (Read 3619 times)
Grandpa Scorpion
Board Junior Member
**






   
WWW | Email

Gender: male
Posts: 70
Methods for Copying Objects  
« on: Jan 23rd, 2003, 3:43am »
Quote | Modify

Hello,
 
I see Symbol has the getAppearance method.  Will it copy all of the grace notes/slurs/ornaments/etc or does it just add references?
 
Related Question: Are there methods for completely cloning an object?  
 
If I get the say 5th symbol of a staff and then add it to the staff.
What is the behavior?  Will it fail/be stored as a reference/ be cloned and appended to the staff?
 
Thanks,
Grandpa
offline
Olivier Guillion
Administrator
*****






   
WWW | Email

Gender: male
Posts: 5963
Re: Methods for Copying Objects  
« Reply #1 on: Jan 23rd, 2003, 10:27am »
Quote | Modify

For most of (not to say all) program objects, this is not possible to declare a local variable that contains a complete object (for ex. a symbol) before it is actually included in its embedder.
 
It means you can set the parameters for a symbol only after it has been actually included in a staff.
 
In the case like the one you describe, if you want to add a symbol which is a copy of the 1st symbol in this staff, you will have to write something like :
Code:

-- Inserts the new symbol at a given time position
newNote=myStaff.InsertNote(timePosition,myStaff.FirstSymbol.Duration,1) -- fake pitch
-- new symbol gets the appearance of 1st symbol
newNote.GetAppearance(myStaff.FirstSymbol)
-- copies also pitch
newNote.Pitch=myStaff.FirstSymbol.Pitch

 
- You add first  a new symbol that has the same duration than the original symbol.
- You then copies all parameters (grace notes, ornaments...) of the original symbol into the new one through GetAppearance method
- You copies the pitch value from the original to the new symbol (not copied through GetAppearance).
 
Hope this helps,
 
« Last Edit: Jan 23rd, 2003, 10:28am by Olivier Guillion » offline

Olivier Guillion
Myriad Software
dewdman42
Board Full Member
***






  Dewdman42   Dewdman42


Posts: 106
Re: Methods for Copying Objects  
« Reply #2 on: Jan 23rd, 2003, 8:10pm »
Quote | Modify

Oh that's a bummer.
offline
Olivier Guillion
Administrator
*****






   
WWW | Email

Gender: male
Posts: 5963
Re: Methods for Copying Objects  
« Reply #3 on: Jan 24th, 2003, 9:26am »
Quote | Modify

on Jan 23rd, 2003, 8:10pm, dewdman42 wrote:
Oh that's a bummer.

 
Why ?
offline

Olivier Guillion
Myriad Software
dewdman42
Board Full Member
***






  Dewdman42   Dewdman42


Posts: 106
Re: Methods for Copying Objects  
« Reply #4 on: Jan 24th, 2003, 9:45am »
Quote | Modify

What if I want to take a bunch of note objects, manipulate their properties in script...duping some notes, changing some notes, etc...and then finally moving into the score.  That would be better than having to put into the score and manipulate in the score.  Otherwise we may end up having to use the score more and more to hold temporary/dummy values which are only needed for algorithmic or other reasons during script execution.  In reality..the score object should only contain "the score", not script data that is in progress...and if the script cannot keep instances of things like notes and other objects....it will mean that either we are more limited with what we can do in the script..or else we willl have to put things on/off the score object as if they were temporary object instances..
 
Or maybe I'm missing something?
offline
dewdman42
Board Full Member
***






  Dewdman42   Dewdman42


Posts: 106
Re: Methods for Copying Objects  
« Reply #5 on: Jan 24th, 2003, 9:48am »
Quote | Modify

Note, this is why I would like to see a memory space for Myrscripts to use for holding objects, and things in a non-visual way.  If the score object is kinda like the DOM, then it would be nice to have another hidden DOM that Myrscript can access to whatever purpose it wants to hold things like note objects, musical phrases or other things that are A) hidden from sight B) not saved with the document, C) available across multiple script executions..
 
« Last Edit: Jan 24th, 2003, 9:49am by dewdman42 » offline
Olivier Guillion
Administrator
*****






   
WWW | Email

Gender: male
Posts: 5963
Re: Methods for Copying Objects  
« Reply #6 on: Jan 24th, 2003, 11:38am »
Quote | Modify

on Jan 24th, 2003, 9:45am, dewdman42 wrote:
What if I want to take a bunch of note objects, manipulate their properties in script...duping some notes, changing some notes, etc...and then finally moving into the score.  That would be better than having to put into the score and manipulate in the score.  Otherwise we may end up having to use the score more and more to hold temporary/dummy values which are only needed for algorithmic or other reasons during script execution.  In reality..the score object should only contain "the score", not script data that is in progress...and if the script cannot keep instances of things like notes and other objects....it will mean that either we are more limited with what we can do in the script..or else we willl have to put things on/off the score object as if they were temporary object instances..

There are some contradictions in your remark.
In music notation, objects are heavily related to each other.  A note by itself has a few meaning if you do not know in which chord it is placed, with which other note it is slurred, at what tempo it is played, etc.
Handling note objects that are not related to anything would disable to use many of their values and methods.
 
You talk about "taking a bunch of note objects", which means you do not need to manipulate single notes, unrelated to each others, but a group of notes that are related to each other, at least by their relative time position in the group. Handling "unembedded" instances of note object would not be of much help.
 
Quote:
Or maybe I'm missing something?

Maybe. There is no need to work on a single score only, or in a single staff. There are ways, using script, to create invisible scores or temporary,  invisible staves into a score.
This enables to manage complex sequences, while keeping an active staff<->symbol relation set.
 
If you only need some parameters of a note to be managed, nothing disables you to create you own custom lua arrays/structures, that can handle as many parameters you need.
You can transfer note parameters in this kind of array/structure, work on it, then create back a note sequence that follows the array values.
For doing this, you just need two functions: a first one that transfers the note parameters you need to process in an array element, and the other one that does the inverse job.
 
Quote:
Note, this is why I would like to see a memory space for Myrscripts to use for holding objects, and things in a non-visual way.

You can consider invisible scores / temporary staves / custom lua array-structures are that kind of memory space.
 
Quote:
If the score object is kinda like the DOM, then it would be nice to have another hidden DOM that Myrscript can access to whatever purpose it wants to hold things like note objects, musical phrases or other things that are A) hidden from sight B) not saved with the document, C) available across multiple script executions..

 
I do not think we will build an complete object database system with persistent objects
The best way to store complex note sequences is still to insert them in a staff and to save the whole stuff into a .MUS file.
Such a file is both hidden from sight, not saved with the document and available across multiple script execution...
You can also create your own file format in which you store only the parameters you need.
 
Hope this helps,
« Last Edit: Jan 24th, 2003, 11:40am by Olivier Guillion » offline

Olivier Guillion
Myriad Software
dewdman42
Board Full Member
***






  Dewdman42   Dewdman42


Posts: 106
Re: Methods for Copying Objects  
« Reply #7 on: Jan 26th, 2003, 2:04am »
Quote | Modify

on Jan 24th, 2003, 11:38am, Olivier Guillion wrote:

There are some contradictions in your remark.

no contradictions..but perhaps miscommunication.
 
Quote:

In music notation, objects are heavily related to each other.  A note by itself has a few meaning if you do not know in which chord it is placed

 
Yes on the staff, yes.  If I want to do some kind of script that generates music...or takes existing music and creates variations...this requires the generation of new note data on the fly, or duplicating existing note data or attributes of such...  not just notes..but any object that can be placed on a score may need to be duplicated, generated, tweaked..ideally OFF-screen and OFF-score.
 
Does Lua have some kind of struct notion?  If I can create arrays of structs, then I can represent note data through other means besides having actual note objects.  Not only notes.  Any kind of object that can be represented on the actual score..we should be able to create IN-MEMORY OFF the score and manipulate in the context of the script.
Quote:

Maybe. There is no need to work on a single score only, or in a single staff. There are ways, using script, to create invisible scores or temporary,  invisible staves into a score.

This will perhaps serve the purpose in a hackish way.
 
Quote:

If you only need some parameters of a note to be managed, nothing disables you to create you own custom lua arrays/structures, that can handle as many parameters you need.

 
Ah..right...ok...this should handle everything Iwanted to do then.  And the hidden staff idea is good too...though it would be nice if we could create hidden staves, etc..which are NOT persisent with the DOM.
 
Quote:

You can transfer note parameters in this kind of array/structure, work on it, then create back a note sequence that follows the array values.
For doing this, you just need two functions: a first one that transfers the note parameters you need to process in an array element, and the other one that does the inverse job.

 
absolutely...  I agree.
 
Quote:

You can consider invisible scores / temporary staves / custom lua array-structures are that kind of memory space.

I think the main advantage of the invisible scores and/or temp staves is that is a memory space which will be good across multiple scripts.  It will be sort of a shared memory..though if we have background scripts on..we have to be careful...no semaphores to control access...
Quote:

I do not think we will build an complete object database system with persistent objects

I agree you shouldn't.  That was never my suggestion.  My suggestion was in fact that I would like to see NON-persistent memory space.  Quite simply...by whatever means possible:
 
1 - memory space that can be shared by one script after another and does not die when a script dies
 
2 - this memory space NOT persistent...nothing in it should be saved with the document.
 
3 - One way or another able to represent all objects that can exist on a score (without having to put them on the persistant score.
 
4 - Ability to represent all objects whether through structs or otherwise OFF the score, so that larger structures can be built behind the scenes without inserting into the real score.  This could be a hidden score, but it should NOT be persisent in any way.
 
Quote:

The best way to store complex note sequences is still to insert them in a staff and to save the whole stuff into a .MUS file.

That may be the EASIEST way, not neccessarily the BEST.  You should be familiar with the concept of double buffering in your GUI design...and in a similar way..there will be plenty of times when scripts need to do things OFF the score and only push things onto the score at the end of an operation or at certain times that make sense..though even complex manipulations might be going on under the covers.
 
Quote:

Such a file is both hidden from sight, not saved with the document and available across multiple script execution...
You can also create your own file format in which you store only the parameters you need.

Ok..  It sounds like this will work..whatever it is...so we'll just wait to see.  Just wanted to make sure we can do the 4 things I listed above..one way or another.
 
Thanks
 
 
Hope this helps, [/quote]
offline
Olivier Guillion
Administrator
*****






   
WWW | Email

Gender: male
Posts: 5963
Re: Methods for Copying Objects  
« Reply #8 on: Jan 26th, 2003, 10:06am »
Quote | Modify

OK.
Here are some information that could help you understanding how it could work :
- In lua, you can use "tables" in a array-like or structure-like way. For example, you can write :
a={}  
a.pitch=123
a.duration=12
b={}
b[1]=a
print(b[1].pitch)
 
in this example, b can be considered as an array of structures. This script will display "123"
 
- For managing complex patterns within a score, you can use Score.NewTemporaryStaff(...) method
It creates an invisible staff on which you can work, and which is deleted automatically when the script ends.
 
- You can also create invisible scores, that can be stored on disk before the script ends.
 
I do not consider this way of working as "hackish", whatever the meaning of this word is  
 
In the same way, I am afraid not to understand what you mean by "double-buffering". We use it in audio output management, but I cannot understand how this notion can be related to scripting or GUI.
 
I presume you have in mind a kind of script you would need to write (or to be written ?), maybe a kind of enhanced accompaniments,  or any other kind of sequence harmonizer or generator, am I wrong ?
 
Even in HA itself, such patterns are stored as regular staves before being harmonized. It is the easiest way to store a set of symbols indeed. Maybe it is not the best, but I cannot see what could be the best way for storing them then.
 
About the ability to manage a "real" object out of any embedder, as I said before, it would result in partially-usable object, because any field or method that is related to its embedder would be then unusable for this kind of orphan object. Maybe it could be done for some kind of objects, but not for all of them.
 
Best Regards,
offline

Olivier Guillion
Myriad Software
dewdman42
Board Full Member
***






  Dewdman42   Dewdman42


Posts: 106
Re: Methods for Copying Objects  
« Reply #9 on: Jan 26th, 2003, 10:44am »
Quote | Modify

on Jan 26th, 2003, 10:06am, Olivier Guillion wrote:
OK.
Here are some information that could help you understanding how it could work :
- In lua, you can use "tables" in a array-like or structure-like way. For example, you can write :
a={}  
a.pitch=123
a.duration=12
b={}
b[1]=a
print(b[1].pitch)
 
in this example, b can be considered as an array of structures. This script will display "123"

 
sounds fine.
 
Quote:

 
- For managing complex patterns within a score, you can use Score.NewTemporaryStaff(...) method
It creates an invisible staff on which you can work, and which is deleted automatically when the script ends.
 

 
Is there a way to store data that does not end until the program is terminated besides writing to invisible staff in the document?  In other words.  I call script A, store data somewhere in memory (not on disk), then I call script B and use the data I just stored.  ??
 
Quote:

 
- You can also create invisible scores, that can be stored on disk before the script ends.
 

 
THAT ^^^ is hackish...FYI  
 
Quote:

 
I do not consider this way of working as "hackish", whatever the meaning of this word is  
 

 
heh heh..  its not that important.  As long as it works.  Perl and many scripting languages are in fact completely hackish in nature...
 
Quote:

In the same way, I am afraid not to understand what you mean by "double-buffering". We use it in audio output management, but I cannot understand how this notion can be related to scripting or GUI.
 

 
I mean it merely "conceptually".  The idea that data needs to be churned around OFF score.  I'm not familiar with audio double buffering.  In graphical interfaces where there is much stuff going on, its very common to use a technique called "double buffering" which basically just means to have two screen buffers so that you paint the hidden one with a bunch of drawing commands and then you basically XOR it onto the visible screen.  Its called double buffering because of the hidden buffer where all the detailed drawing commands take place, but the OS can do the XOR of the final product very quickly, so less "flashing" will occurr.  It makes for a cleaner GUI when there is lots of movement going on.
 
I meant to say "conceptually"..that when writing scripts that deal with the score it would be very handy to be able to have a hidden score that can accomodate all the same objects that the score can accomodate so that operations can be performed on this hidden area and then updates are made to the actual score(the one that will be saved to disk) at the END of the calculations, rather than as it goes.  Its similar to double buffering in this regard...that the score is not touched until the end and all the calculations take place in some hidden area that will not effect the score or the screen.
 
Perhaps this is realized with the invisible staff feature you were talking about, though I would really like to see it NOT be part of the saved document.  And of course, a script can write a bunch of code using the structs and stuff as you suggested above to organize the data using LUA.  
 
Can you see that some scripts will involve a LOT of LUA code in order to represent the the various score objects?  Just to do it right...each script will need to contain a lot of code just for this task alone.   It would be so much easier if we could just use HA objects..instantiating them and holding them SOMEWHERE in memory.  And then be able to refer to them with LUA the same way that we can refer to actual objects on the score.  The only thing I'm saying is that these objects would NOT be saved with the score..they would exist only in memory.
 
Quote:

I presume you have in mind a kind of script you would need to write (or to be written ?), maybe a kind of enhanced accompaniments,  or any other kind of sequence harmonizer or generator, am I wrong ?

I have many ideas for script..  Other people are more interested in accompaniments...and I think there is lots of opportunity for people to write some cool scripts that do stuff like that.  I am going to develop scripts to aid in the compositional process.  To keep track of musical phrases and to use them throughout the composing process in intelligent ways.  Until the MyrScript version of HA comes out, I'm not entirely sure how I will approach the problem, but I do believe it would be easier if I could instantiate objects that are just like what goes in the score...without putting them in the score.
 
Quote:

Even in HA itself, such patterns are stored as regular staves before being harmonized. It is the easiest way to store a set of symbols indeed. Maybe it is not the best, but I cannot see what could be the best way for storing them then.

 
Ok..well this may be completely enough.  If we could have some internal staves which are NOT saved with the document, and are available globally to all scripts.. that would absolutely enable the ability to create any kind of HA object and use it in LUA.
offline
dewdman42
Board Full Member
***






  Dewdman42   Dewdman42


Posts: 106
Re: Methods for Copying Objects  
« Reply #10 on: Jan 26th, 2003, 10:52am »
Quote | Modify

And i might add...that I have decided to try to do what I plan to do with HA.  However...if I am unable to make it work with LUA, then I am going to move to C++ and write some Finale Plugins to do what I want.  And finally if that doesn't work then I shall write my own program.  But I don't really want to spend that much time writing software.  I'd rather spend my time writing music.  So I remain very hopeful that HA or Finale will be able to be tweaked through scripts or plugins to do what I wish  composing program would do.
 
I would rather make it work in HA though because I find HA much simpler and more appropriate for the composing process..where Finale is so focused on typesetting correctness that it gets in the way of the compositional process (IMHO).
 
cheers
offline
Olivier Guillion
Administrator
*****






   
WWW | Email

Gender: male
Posts: 5963
Re: Methods for Copying Objects  
« Reply #11 on: Jan 26th, 2003, 11:31am »
Quote | Modify

OK again.
 
I presume MyrScript is yet too young (in fact, it is still not born) to know exactly what kind of features could really miss for building some kind of scripts in a convenient way.
I think we will have to analyze the problem on a concrete case as soon as a first beta-version of MyrScript will be available. Anyway, enabling to instantiate some objects would not change what we already implemented.
 
What you call double-buffering in GUI context is what I call "offscreen buffers". Maybe the terms "invisible staff" or "invisible score" are confusing. You can consider them as "offscreen staves" and "offscreen scores", these objects only existing in memory except if the script explicitely saves them on disk. Offscreen buffers are used in GUI to let the drawing process look nicer. If it is for the same reason you need "offscreen objects" in MyrScript, please consider the score is updated graphically only at the end of the script, or when explicitely asked during the script processing.
 
I still cannot understand how and why several scripts could share a same memory area, but I presume it could have an application in some cases. Anyway, you do not have to consider storing on disk is different from storing in memory. Some kind of temporary files could handle shared data between scripts.
 
At last, I *really* do not know what "hackish" mean. It is not a joke. According to my impression about this term, I presume it means "a way of workarounding a problem by adding features that do the job in a bad-looking way". Am I right ?
 
offline

Olivier Guillion
Myriad Software
dewdman42
Board Full Member
***






  Dewdman42   Dewdman42


Posts: 106
Re: Methods for Copying Objects  
« Reply #12 on: Jan 26th, 2003, 9:21pm »
Quote | Modify

on Jan 26th, 2003, 11:31am, Olivier Guillion wrote:
OK again.
 
I presume MyrScript is yet too young (in fact, it is still not born) to know exactly what kind of features could really miss for building some kind of scripts in a convenient way.
I think we will have to analyze the problem on a concrete case as soon as a first beta-version of MyrScript will be available. Anyway, enabling to instantiate some objects would not change what we already implemented.
 

 
sounds fine
 
Quote:

 
What you call double-buffering in GUI context is what I call "offscreen buffers". Maybe the terms "invisible staff" or "invisible score" are confusing. You can consider them as "offscreen staves" and "offscreen scores", these objects only existing in memory except if the script explicitely saves them on disk.  
 

 
Sounds like it might work.  We'll just have to see what happens when real scripts start rolling out in years to come I guess..
 
Quote:

 
Offscreen buffers are used in GUI to let the drawing process look nicer. If it is for the same reason you need "offscreen objects" in MyrScript, please consider the score is updated graphically only at the end of the script, or when explicitely asked during the script processing.
 

 
Again, I was trying to be "conceptual", not literal.  I'm not concerned about the graphical drawing.  Its a concept only.  In GUI world...you have visual and you have the "offscreen buffer" where all the work takes place.  With a musical score...forget about visual concept.  You have a score...a score which can be saved to disk as a MUS file.  Then you need to have some background space where objects that MIGHT go into this score can be manipulated.  If we have to use LUA structs to represent those same objects..it can be done, but it will require a lot of superfluous script code just to manage the abstractions for each script.  If LUA could simply instantiate and reference instances of those different objects then I could, for example, keep an array of note objects to be latere propogated into the score when the script is truly ready to do so..not before then.  
 
I could use this background invisible staff like a sort of array container, but that sounds very hackish to me.  Sorry if that term offends you, I do not mean to offend.   And if that is what we end up with, then we'll hack away and make stuff work.  My only original statement was "That is a bummer".  And truly it is a bummer if we have to resort to hackish tricks or cumbersome script trickery in order to simply represent an array of note objects in memory to be used across more than one script or even just within one script.
 
Quote:

I still cannot understand how and why several scripts could share a same memory area, but I presume it could have an application in some cases.  

 
I would rather have many little scriplets then one big background script.  Temporary files can be used.  They are messier and slower.  
 
Quote:

Anyway, you do not have to consider storing on disk is different from storing in memory. Some kind of temporary files could handle shared data between scripts.

 
Uhhmm, having to store on disk is slower for one thing..messier for another.  Aka..."hackish".  B-)
 
Quote:

 
At last, I *really* do not know what "hackish" mean. It is not a joke. According to my impression about this term, I presume it means "a way of workarounding a problem by adding features that do the job in a bad-looking way". Am I right ?
 

 
Bad looking, or badly structured, difficult to understand and maintain, etc..  Its a very subjective term..so naturally we may not agree to what is hackish or not.  Some people who are complete hacks don't think they are hacks.  Sometimes "hackish" code can simply come from sloppy programming, or from someone that doesn't really know what they are doing so they just slap the code together.  
 
however, sometimes hackish code results, not at any fault of the programmer, but because the programming environment requires it to make things work.  Perl, for example, while very useful and powerful in many ways...has end up producing millions of lines of hackish code over the years all over the place.  In perl you have to go way out of your way to write a well structured program.  
 
I'm not a big fan of Java, but one of the big things in its favor is that Java naturally inclines people to write well structured code.   Perl does not.  What will HA/Lua be?
 
It may be academic what we're talking about now and really not relavent.  
 
I'm growing tired of this discussion anyway.  Rather than argue with me about my suggestions, I'd rather you just listen to them, consider them and then you can choose to do whatever you want.  My comments were never meant to start a debate with you, they were meant to perhaps inspire you.  But it seems that you would rather debate.  
 
As far as I'm concerned, just do whatever you're going to do and we'll see whether it will do what I want or not...    B-)  
 
 
I'm just glad to hear that you're adding any kind of scripting at all.
 
cheers
« Last Edit: Jan 26th, 2003, 9:24pm by dewdman42 » offline
Olivier Guillion
Administrator
*****






   
WWW | Email

Gender: male
Posts: 5963
Re: Methods for Copying Objects  
« Reply #13 on: Jan 26th, 2003, 10:23pm »
Quote | Modify

OK. Let's close this debate for a while then.
Please consider I did not answer your message just for the pleasure of arguing, but simply understand well what you ask for, and try to see how the already written program structure could match your requirements.
 
.. And also to see whether this is possible to implement a cumbersome "hackish" method for doing the job in a complex way instead of writing a few lines of code that could  match exactly your requirements.
offline

Olivier Guillion
Myriad Software
dewdman42
Board Full Member
***






  Dewdman42   Dewdman42


Posts: 106
Re: Methods for Copying Objects  
« Reply #14 on: Jan 26th, 2003, 10:29pm »
Quote | Modify

on Jan 26th, 2003, 10:23pm, Olivier Guillion wrote:
.. writing a few lines of code that could  match exactly your requirements.

 
B-)
offline
Pages: 1 2  Reply | Notify of replies | Print

« Previous topic | Next topic »

« Myriad Forum » Powered by YaBB 1 Gold - SP 1.1!
YaBB © 2000-2002,
Xnull. All Rights Reserved.

Top of page
Last update:  (c) Myriad 2013