Re: Synchronisation of sound and vision

[Pi Digital via use-livecode]

I worked on a similar project. I ended up splitting the audio into smaller sub 
clips and triggered each to play in turn. callbacks were a pain in the b

Sean Cole
Pi Digital Productions Ltd
eMail Ts & Cs


> On 12 Feb 2020, at 22:55, Richard Gaskin via use-livecode 
>  wrote:
> 
> Callbacks are the way to go, but note that LC's callbacks won't work on 
> Linux.
> 
> Because there's no functioning LC player object for Linux at all.
> 
> -- 
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> 
> ambassa...@fourthworld.comhttp://www.FourthWorld.com
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Synchronisation of sound and vision

[Richard Gaskin via use-livecode]

Callbacks are the way to go, but note that LC's callbacks won't work on 
Linux.


Because there's no functioning LC player object for Linux at all.

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Synchronisation of sound and vision

[Tore Nilsen via use-livecode]

I wasn’t aware of this, sounds great! (Pun intended) I will have to go back to 
my application and experiment a bit before the next batch of student recordings 
lands on my desktop. (You know, pun…)

Tore

> 12. feb. 2020 kl. 21:47 skrev Devin Asay via use-livecode 
> :
> 
> Tore,
> 
> You can do audio recording on Mac now using the mergMicrophone library. It 
> works great, and I believe is available in every edition of LC, including 
> Community.
> 
> Devin
> 
>> On Feb 12, 2020, at 12:11 PM, Tore Nilsen via use-livecode 
>>  wrote:
>> 
>> Devin,
>> I haven’t used callbacks much, and so far I haven’t run in to any problems. 
>> If missing callbacks is still an issue, then I agree with you that setting 
>> startTime and endTime is the best option. I use this method in a small 
>> application I have made for myself where I write comments to audio files 
>> handed in by my English students. They can then control playback of the 
>> segments I have commented on by clicking links in the field that shows the 
>> comments. The lack of audio recording capability on Mac has forced me to use 
>> written feedback where I otherwise would have preferred using two players 
>> and audio feedback.
>> 
>> Regards
>> Tore
>> 
>>> 12. feb. 2020 kl. 19:57 skrev Devin Asay via use-livecode 
>>> :
>>> 
>>> Tore,
>>> 
>>> I would agree if callbacks were 100% reliable. I have tried them in the 
>>> past and found that in some cases they were missed. I never had any trouble 
>>> when using time indices. But I should say that I haven’t needed to do this 
>>> for several years, and the callbacks in the new player object might be 
>>> completely reliable.
>>> 
>>> In other ways creating time indices makes your application more flexible, 
>>> however. It’s dead simple, for instance, to set up an application where you 
>>> can click on a line of text and play just that line. Set the startTime, set 
>>> the endTime, set the playSelection to true, start playing. Done. That would 
>>> be a little more challenging if all you had was callbacks.
>>> 
>>> One of the great things about LiveCode is that there is almost always more 
>>> than one way to do what you want.
>>> 
>>> Regards,
>>> 
>>> Devin
>>> 
>>> 
>>> On Feb 12, 2020, at 9:55 AM, Tore Nilsen via use-livecode 
>>> mailto:use-livecode@lists.runrev.com>> wrote:
>>> 
>>> Using callbacks negate the need to fiddle with duration or  timescales and 
>>> start or stop times. It uses the sampling intervals as is, regardless of 
>>> time. In my opinion it is much easier than trying to calculate start and 
>>> end times. You can easily handle large audio/video files using callbacks. I 
>>> would recommend using one file per poem though, this simplifies the 
>>> handling of the messages sent from the player. You can basically use the 
>>> same message for all files, resetting a counter variable each time you load 
>>> a new file to handle with line you would like to act upon.
>>> 
>>> You could also store the callbacks for each audio file in a text file and 
>>> set the callbacks as a part of the handler used to load each audio file.
>>> 
>>> Regards
>>> Tore
>>> 
>>> 12. feb. 2020 kl. 16:49 skrev Devin Asay via use-livecode 
>>> mailto:use-livecode@lists.runrev.com>>:
>>> 
>>> Graham,
>>> 
>>> Take a look at the duration and the timeScale properties of player objects. 
>>> By dividing duration by timeScale you get the length of the video in 
>>> seconds.
>>> 
>>> 
>>> put the duration of player  “foo” / the timescale of player  “foo” into 
>>> totalSeconds
>>> 
>>> What you are contemplating is very doable, but you’ll have to do a fair 
>>> amount of work to do to get the synching right. You can take one of several 
>>> approaches:
>>> 
>>> - Calculate times as above to predict when to show/highlight the next line. 
>>> Can be tricky with long video files and rounding errors.
>>> 
>>> - Check the currentTime property of the player to determine the startTime 
>>> and endTime of each spoken line, and set the playSelection of the player to 
>>> true. When the played segment ends, immediately load the following start 
>>> and end times and play again. Something like this, from memory:
>>> 
>>> set the startTime of player “foo” to 444
>>> set the endTime of player “foo” to 999
>>> set the currentTime of player “foo” to the startTime of player “foo”
>>> set the playerSelection of player “foo” to true
>>> start player “foo"
>>> - Break up the video or audio file into separate files, one line per file, 
>>> then play each succeeding file when the previous one reaches its end. The 
>>> playStopped message is your friend here.
>>> 
>>> Like I said, it’s doable, but takes a bit of thought and planning, creating 
>>> segment indexes, that sort of thing.
>>> 
>>> Hope this helps.
>>> 
>>> Devin
> 
> Devin Asay
> Director
> Office of Digital Humanities
> Brigham Young University
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit

Re: Synchronisation of sound and vision

[Devin Asay via use-livecode]

Tore,

You can do audio recording on Mac now using the mergMicrophone library. It 
works great, and I believe is available in every edition of LC, including 
Community.

Devin

> On Feb 12, 2020, at 12:11 PM, Tore Nilsen via use-livecode 
>  wrote:
> 
> Devin,
> I haven’t used callbacks much, and so far I haven’t run in to any problems. 
> If missing callbacks is still an issue, then I agree with you that setting 
> startTime and endTime is the best option. I use this method in a small 
> application I have made for myself where I write comments to audio files 
> handed in by my English students. They can then control playback of the 
> segments I have commented on by clicking links in the field that shows the 
> comments. The lack of audio recording capability on Mac has forced me to use 
> written feedback where I otherwise would have preferred using two players and 
> audio feedback.
> 
> Regards
> Tore
> 
>> 12. feb. 2020 kl. 19:57 skrev Devin Asay via use-livecode 
>> :
>> 
>> Tore,
>> 
>> I would agree if callbacks were 100% reliable. I have tried them in the past 
>> and found that in some cases they were missed. I never had any trouble when 
>> using time indices. But I should say that I haven’t needed to do this for 
>> several years, and the callbacks in the new player object might be 
>> completely reliable.
>> 
>> In other ways creating time indices makes your application more flexible, 
>> however. It’s dead simple, for instance, to set up an application where you 
>> can click on a line of text and play just that line. Set the startTime, set 
>> the endTime, set the playSelection to true, start playing. Done. That would 
>> be a little more challenging if all you had was callbacks.
>> 
>> One of the great things about LiveCode is that there is almost always more 
>> than one way to do what you want.
>> 
>> Regards,
>> 
>> Devin
>> 
>> 
>> On Feb 12, 2020, at 9:55 AM, Tore Nilsen via use-livecode 
>> mailto:use-livecode@lists.runrev.com>> wrote:
>> 
>> Using callbacks negate the need to fiddle with duration or  timescales and 
>> start or stop times. It uses the sampling intervals as is, regardless of 
>> time. In my opinion it is much easier than trying to calculate start and end 
>> times. You can easily handle large audio/video files using callbacks. I 
>> would recommend using one file per poem though, this simplifies the handling 
>> of the messages sent from the player. You can basically use the same message 
>> for all files, resetting a counter variable each time you load a new file to 
>> handle with line you would like to act upon.
>> 
>> You could also store the callbacks for each audio file in a text file and 
>> set the callbacks as a part of the handler used to load each audio file.
>> 
>> Regards
>> Tore
>> 
>> 12. feb. 2020 kl. 16:49 skrev Devin Asay via use-livecode 
>> mailto:use-livecode@lists.runrev.com>>:
>> 
>> Graham,
>> 
>> Take a look at the duration and the timeScale properties of player objects. 
>> By dividing duration by timeScale you get the length of the video in seconds.
>> 
>> 
>> put the duration of player  “foo” / the timescale of player  “foo” into 
>> totalSeconds
>> 
>> What you are contemplating is very doable, but you’ll have to do a fair 
>> amount of work to do to get the synching right. You can take one of several 
>> approaches:
>> 
>> - Calculate times as above to predict when to show/highlight the next line. 
>> Can be tricky with long video files and rounding errors.
>> 
>> - Check the currentTime property of the player to determine the startTime 
>> and endTime of each spoken line, and set the playSelection of the player to 
>> true. When the played segment ends, immediately load the following start and 
>> end times and play again. Something like this, from memory:
>> 
>> set the startTime of player “foo” to 444
>> set the endTime of player “foo” to 999
>> set the currentTime of player “foo” to the startTime of player “foo”
>> set the playerSelection of player “foo” to true
>> start player “foo"
>> - Break up the video or audio file into separate files, one line per file, 
>> then play each succeeding file when the previous one reaches its end. The 
>> playStopped message is your friend here.
>> 
>> Like I said, it’s doable, but takes a bit of thought and planning, creating 
>> segment indexes, that sort of thing.
>> 
>> Hope this helps.
>> 
>> Devin

Devin Asay
Director
Office of Digital Humanities
Brigham Young University

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Synchronisation of sound and vision

[Tore Nilsen via use-livecode]

Devin,
I haven’t used callbacks much, and so far I haven’t run in to any problems. If 
missing callbacks is still an issue, then I agree with you that setting 
startTime and endTime is the best option. I use this method in a small 
application I have made for myself where I write comments to audio files handed 
in by my English students. They can then control playback of the segments I 
have commented on by clicking links in the field that shows the comments. The 
lack of audio recording capability on Mac has forced me to use written feedback 
where I otherwise would have preferred using two players and audio feedback.

Regards
Tore

> 12. feb. 2020 kl. 19:57 skrev Devin Asay via use-livecode 
> :
> 
> Tore,
> 
> I would agree if callbacks were 100% reliable. I have tried them in the past 
> and found that in some cases they were missed. I never had any trouble when 
> using time indices. But I should say that I haven’t needed to do this for 
> several years, and the callbacks in the new player object might be completely 
> reliable.
> 
> In other ways creating time indices makes your application more flexible, 
> however. It’s dead simple, for instance, to set up an application where you 
> can click on a line of text and play just that line. Set the startTime, set 
> the endTime, set the playSelection to true, start playing. Done. That would 
> be a little more challenging if all you had was callbacks.
> 
> One of the great things about LiveCode is that there is almost always more 
> than one way to do what you want.
> 
> Regards,
> 
> Devin
> 
> 
> On Feb 12, 2020, at 9:55 AM, Tore Nilsen via use-livecode 
> mailto:use-livecode@lists.runrev.com>> wrote:
> 
> Using callbacks negate the need to fiddle with duration or  timescales and 
> start or stop times. It uses the sampling intervals as is, regardless of 
> time. In my opinion it is much easier than trying to calculate start and end 
> times. You can easily handle large audio/video files using callbacks. I would 
> recommend using one file per poem though, this simplifies the handling of the 
> messages sent from the player. You can basically use the same message for all 
> files, resetting a counter variable each time you load a new file to handle 
> with line you would like to act upon.
> 
> You could also store the callbacks for each audio file in a text file and set 
> the callbacks as a part of the handler used to load each audio file.
> 
> Regards
> Tore
> 
> 12. feb. 2020 kl. 16:49 skrev Devin Asay via use-livecode 
> mailto:use-livecode@lists.runrev.com>>:
> 
> Graham,
> 
> Take a look at the duration and the timeScale properties of player objects. 
> By dividing duration by timeScale you get the length of the video in seconds.
> 
> 
> put the duration of player  “foo” / the timescale of player  “foo” into 
> totalSeconds
> 
> What you are contemplating is very doable, but you’ll have to do a fair 
> amount of work to do to get the synching right. You can take one of several 
> approaches:
> 
> - Calculate times as above to predict when to show/highlight the next line. 
> Can be tricky with long video files and rounding errors.
> 
> - Check the currentTime property of the player to determine the startTime and 
> endTime of each spoken line, and set the playSelection of the player to true. 
> When the played segment ends, immediately load the following start and end 
> times and play again. Something like this, from memory:
> 
> set the startTime of player “foo” to 444
> set the endTime of player “foo” to 999
> set the currentTime of player “foo” to the startTime of player “foo”
> set the playerSelection of player “foo” to true
> start player “foo"
> - Break up the video or audio file into separate files, one line per file, 
> then play each succeeding file when the previous one reaches its end. The 
> playStopped message is your friend here.
> 
> Like I said, it’s doable, but takes a bit of thought and planning, creating 
> segment indexes, that sort of thing.
> 
> Hope this helps.
> 
> Devin
> 
> 
> On Feb 12, 2020, at 5:28 AM, Graham Samuel via use-livecode 
> mailto:use-livecode@lists.runrev.com>>
>  wrote:
> 
> Thanks, that’s a start - I will look at the dictionary. I suppose the 
> callbacks rely on one analysing how long each line/word takes the performer 
> to say. It’s a lot of work, but there’s no way around it since potentially 
> every line takes a different length of time to recite. If it’s too much work, 
> I guess I can just display the whole text and have one callback at the end of 
> each recording. Maybe that is really the practical solution for a large body 
> of work (say all the Shakespeare sonnets, for example).
> 
> Anyway thanks for the hint.
> 
> Graham
> 
> On 12 Feb 2020, at 12:16, Tore Nilsen via use-livecode 
> mailto:use-livecode@lists.runrev.com>>
>  wrote:
> 
> You will have to use the callbacks property of the player to do what you want 

Re: Synchronisation of sound and vision

[Devin Asay via use-livecode]

Tore,

I would agree if callbacks were 100% reliable. I have tried them in the past 
and found that in some cases they were missed. I never had any trouble when 
using time indices. But I should say that I haven’t needed to do this for 
several years, and the callbacks in the new player object might be completely 
reliable.

In other ways creating time indices makes your application more flexible, 
however. It’s dead simple, for instance, to set up an application where you can 
click on a line of text and play just that line. Set the startTime, set the 
endTime, set the playSelection to true, start playing. Done. That would be a 
little more challenging if all you had was callbacks.

One of the great things about LiveCode is that there is almost always more than 
one way to do what you want.

Regards,

Devin


On Feb 12, 2020, at 9:55 AM, Tore Nilsen via use-livecode 
mailto:use-livecode@lists.runrev.com>> wrote:

Using callbacks negate the need to fiddle with duration or  timescales and 
start or stop times. It uses the sampling intervals as is, regardless of time. 
In my opinion it is much easier than trying to calculate start and end times. 
You can easily handle large audio/video files using callbacks. I would 
recommend using one file per poem though, this simplifies the handling of the 
messages sent from the player. You can basically use the same message for all 
files, resetting a counter variable each time you load a new file to handle 
with line you would like to act upon.

You could also store the callbacks for each audio file in a text file and set 
the callbacks as a part of the handler used to load each audio file.

Regards
Tore

12. feb. 2020 kl. 16:49 skrev Devin Asay via use-livecode 
mailto:use-livecode@lists.runrev.com>>:

Graham,

Take a look at the duration and the timeScale properties of player objects. By 
dividing duration by timeScale you get the length of the video in seconds.


put the duration of player  “foo” / the timescale of player  “foo” into 
totalSeconds

What you are contemplating is very doable, but you’ll have to do a fair amount 
of work to do to get the synching right. You can take one of several approaches:

- Calculate times as above to predict when to show/highlight the next line. Can 
be tricky with long video files and rounding errors.

- Check the currentTime property of the player to determine the startTime and 
endTime of each spoken line, and set the playSelection of the player to true. 
When the played segment ends, immediately load the following start and end 
times and play again. Something like this, from memory:

set the startTime of player “foo” to 444
set the endTime of player “foo” to 999
set the currentTime of player “foo” to the startTime of player “foo”
set the playerSelection of player “foo” to true
start player “foo"
- Break up the video or audio file into separate files, one line per file, then 
play each succeeding file when the previous one reaches its end. The 
playStopped message is your friend here.

Like I said, it’s doable, but takes a bit of thought and planning, creating 
segment indexes, that sort of thing.

Hope this helps.

Devin


On Feb 12, 2020, at 5:28 AM, Graham Samuel via use-livecode 
mailto:use-livecode@lists.runrev.com>>
 wrote:

Thanks, that’s a start - I will look at the dictionary. I suppose the callbacks 
rely on one analysing how long each line/word takes the performer to say. It’s 
a lot of work, but there’s no way around it since potentially every line takes 
a different length of time to recite. If it’s too much work, I guess I can just 
display the whole text and have one callback at the end of each recording. 
Maybe that is really the practical solution for a large body of work (say all 
the Shakespeare sonnets, for example).

Anyway thanks for the hint.

Graham

On 12 Feb 2020, at 12:16, Tore Nilsen via use-livecode 
mailto:use-livecode@lists.runrev.com>>
 wrote:

You will have to use the callbacks property of the player to do what you want 
to do. The callbacks list would be your cues. From the dictionary:

The callbacks of a player <> is a list of callbacks, one per line. Each 
callback consists of an interval number, a comma, and a message <> name.


Regards
Tore Nilsen


12. feb. 2020 kl. 11:25 skrev Graham Samuel via use-livecode 
mailto:use-livecode@lists.runrev.com>>:

Folks, forgive my ignorance, but it’s a long time since I considered the 
following and wondered what pitfalls there are.

I have in mind a project where a recording of someone reading a poetry text 
(“old fashioned” poetry in metrical lines) needs to be synchronised to the 
display text itself on the screen, ideally so that a cursor or highlight would 
move from word to word with the speaker, although that would almost certainly 
involve too much work for the developer (me), or at least highlight lines as 
they are being spoken.

Re: Synchronisation of sound and vision

[Graham Samuel via use-livecode]

Thanks Tore, Devin, Peter and Alex! There is a lot to chew on here. I do in 
fact have one file per poem - the user of the program will see each poem as 
different object, as it were, so there would be no advantage to combining them. 
I will try to do some experiments shortly. Doubtless after that there will be 
more questions.

The issue of user platform preferences (desktop or app etc) which is discussed 
by Peter must be a universal one. I have previously experienced the gotcha of 
school labs not wanting to install applications. But I am getting far ahead of 
myself, since there are so many other issues to consider before i get near to 
making a proper platform decision.

Graham

> On 12 Feb 2020, at 17:55, Tore Nilsen via use-livecode 
>  wrote:
> 
> Using callbacks negate the need to fiddle with duration or  timescales and 
> start or stop times. It uses the sampling intervals as is, regardless of 
> time. In my opinion it is much easier than trying to calculate start and end 
> times. You can easily handle large audio/video files using callbacks. I would 
> recommend using one file per poem though, this simplifies the handling of the 
> messages sent from the player. You can basically use the same message for all 
> files, resetting a counter variable each time you load a new file to handle 
> with line you would like to act upon.
> 
> You could also store the callbacks for each audio file in a text file and set 
> the callbacks as a part of the handler used to load each audio file.
> 
> Regards 
> Tore
> 
>> 12. feb. 2020 kl. 16:49 skrev Devin Asay via use-livecode 
>> :
>> 
>> Graham,
>> 
>> Take a look at the duration and the timeScale properties of player objects. 
>> By dividing duration by timeScale you get the length of the video in seconds.
>> 
>> 
>> put the duration of player  “foo” / the timescale of player  “foo” into 
>> totalSeconds
>> 
>> What you are contemplating is very doable, but you’ll have to do a fair 
>> amount of work to do to get the synching right. You can take one of several 
>> approaches:
>> 
>> - Calculate times as above to predict when to show/highlight the next line. 
>> Can be tricky with long video files and rounding errors.
>> 
>> - Check the currentTime property of the player to determine the startTime 
>> and endTime of each spoken line, and set the playSelection of the player to 
>> true. When the played segment ends, immediately load the following start and 
>> end times and play again. Something like this, from memory:
>> 
>> set the startTime of player “foo” to 444
>> set the endTime of player “foo” to 999
>> set the currentTime of player “foo” to the startTime of player “foo”
>> set the playerSelection of player “foo” to true
>> start player “foo"
>> - Break up the video or audio file into separate files, one line per file, 
>> then play each succeeding file when the previous one reaches its end. The 
>> playStopped message is your friend here.
>> 
>> Like I said, it’s doable, but takes a bit of thought and planning, creating 
>> segment indexes, that sort of thing.
>> 
>> Hope this helps.
>> 
>> Devin
>> 
>> 
>> On Feb 12, 2020, at 5:28 AM, Graham Samuel via use-livecode 
>> mailto:use-livecode@lists.runrev.com>> wrote:
>> 
>> Thanks, that’s a start - I will look at the dictionary. I suppose the 
>> callbacks rely on one analysing how long each line/word takes the performer 
>> to say. It’s a lot of work, but there’s no way around it since potentially 
>> every line takes a different length of time to recite. If it’s too much 
>> work, I guess I can just display the whole text and have one callback at the 
>> end of each recording. Maybe that is really the practical solution for a 
>> large body of work (say all the Shakespeare sonnets, for example).
>> 
>> Anyway thanks for the hint.
>> 
>> Graham
>> 
>> On 12 Feb 2020, at 12:16, Tore Nilsen via use-livecode 
>> mailto:use-livecode@lists.runrev.com>> wrote:
>> 
>> You will have to use the callbacks property of the player to do what you 
>> want to do. The callbacks list would be your cues. From the dictionary:
>> 
>> The callbacks of a player <> is a list of callbacks, one per line. Each 
>> callback consists of an interval number, a comma, and a message <> name.
>> 
>> 
>> Regards
>> Tore Nilsen
>> 
>> 
>> 12. feb. 2020 kl. 11:25 skrev Graham Samuel via use-livecode 
>> mailto:use-livecode@lists.runrev.com>>:
>> 
>> Folks, forgive my ignorance, but it’s a long time since I considered the 
>> following and wondered what pitfalls there are.
>> 
>> I have in mind a project where a recording of someone reading a poetry text 
>> (“old fashioned” poetry in metrical lines) needs to be synchronised to the 
>> display text itself on the screen, ideally so that a cursor or highlight 
>> would move from word to word with the speaker, although that would almost 
>> certainly involve too much work for the developer (me), or at least 
>> highlight lines as they are being spoken. I see that one would inevitably 
>> hav

Re: Synchronisation of sound and vision

[Tore Nilsen via use-livecode]

Using callbacks negate the need to fiddle with duration or  timescales and 
start or stop times. It uses the sampling intervals as is, regardless of time. 
In my opinion it is much easier than trying to calculate start and end times. 
You can easily handle large audio/video files using callbacks. I would 
recommend using one file per poem though, this simplifies the handling of the 
messages sent from the player. You can basically use the same message for all 
files, resetting a counter variable each time you load a new file to handle 
with line you would like to act upon.

You could also store the callbacks for each audio file in a text file and set 
the callbacks as a part of the handler used to load each audio file.

Regards 
Tore

> 12. feb. 2020 kl. 16:49 skrev Devin Asay via use-livecode 
> :
> 
> Graham,
> 
> Take a look at the duration and the timeScale properties of player objects. 
> By dividing duration by timeScale you get the length of the video in seconds.
> 
> 
> put the duration of player  “foo” / the timescale of player  “foo” into 
> totalSeconds
> 
> What you are contemplating is very doable, but you’ll have to do a fair 
> amount of work to do to get the synching right. You can take one of several 
> approaches:
> 
> - Calculate times as above to predict when to show/highlight the next line. 
> Can be tricky with long video files and rounding errors.
> 
> - Check the currentTime property of the player to determine the startTime and 
> endTime of each spoken line, and set the playSelection of the player to true. 
> When the played segment ends, immediately load the following start and end 
> times and play again. Something like this, from memory:
> 
> set the startTime of player “foo” to 444
> set the endTime of player “foo” to 999
> set the currentTime of player “foo” to the startTime of player “foo”
> set the playerSelection of player “foo” to true
> start player “foo"
> - Break up the video or audio file into separate files, one line per file, 
> then play each succeeding file when the previous one reaches its end. The 
> playStopped message is your friend here.
> 
> Like I said, it’s doable, but takes a bit of thought and planning, creating 
> segment indexes, that sort of thing.
> 
> Hope this helps.
> 
> Devin
> 
> 
> On Feb 12, 2020, at 5:28 AM, Graham Samuel via use-livecode 
> mailto:use-livecode@lists.runrev.com>> wrote:
> 
> Thanks, that’s a start - I will look at the dictionary. I suppose the 
> callbacks rely on one analysing how long each line/word takes the performer 
> to say. It’s a lot of work, but there’s no way around it since potentially 
> every line takes a different length of time to recite. If it’s too much work, 
> I guess I can just display the whole text and have one callback at the end of 
> each recording. Maybe that is really the practical solution for a large body 
> of work (say all the Shakespeare sonnets, for example).
> 
> Anyway thanks for the hint.
> 
> Graham
> 
> On 12 Feb 2020, at 12:16, Tore Nilsen via use-livecode 
> mailto:use-livecode@lists.runrev.com>> wrote:
> 
> You will have to use the callbacks property of the player to do what you want 
> to do. The callbacks list would be your cues. From the dictionary:
> 
> The callbacks of a player <> is a list of callbacks, one per line. Each 
> callback consists of an interval number, a comma, and a message <> name.
> 
> 
> Regards
> Tore Nilsen
> 
> 
> 12. feb. 2020 kl. 11:25 skrev Graham Samuel via use-livecode 
> mailto:use-livecode@lists.runrev.com>>:
> 
> Folks, forgive my ignorance, but it’s a long time since I considered the 
> following and wondered what pitfalls there are.
> 
> I have in mind a project where a recording of someone reading a poetry text 
> (“old fashioned” poetry in metrical lines) needs to be synchronised to the 
> display text itself on the screen, ideally so that a cursor or highlight 
> would move from word to word with the speaker, although that would almost 
> certainly involve too much work for the developer (me), or at least highlight 
> lines as they are being spoken. I see that one would inevitably have to add 
> cues to the spoken text file to fire off the highlighting, which is indeed an 
> unavoidable amount of work, but can it be done at all in LC? For example, 
> what form would the cues take?
> 
> TIA
> 
> Graham
> ___
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> Devin Asay
> Director
> Office of Digital Humanities
> Brigham Young University
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://l

Re: HyperCard: the Myst story

[Peter Bogdanoff via use-livecode]

Hi Graham,

I congratulate you on your ambition to do this! It seems that the days are long 
gone when people will pay attention to a content product because it is just 
that. All the attention (i.e. funding) has moved on to scalable platforms 
rather than individual works of artifice!

Yes, when we started showing people our desktop Music In the Air program they 
would ask immediately about web delivery, and I looked into LC’s HTML 5. But it 
definitely turns out that desktop is more doable, cheaper, and technically 
capable for our program, so we’re sticking with that for the present. 

Most of our customers have their own personal machine, but school labs can be 
problematic when the lab admin doesn’t want to install an application. I don’t 
have enough experience with this to say definitely, but very likely schools 
with younger students will rely on lab computers with possible restrictions. 
Also, an app with its required installation probably will have less 
discoverability by potential users compared to a web application which can be 
tried out and used immediately.

I’ll address your questions about sync in your other posting.

Peter
ArtsInteractive

> On Feb 12, 2020, at 5:11 AM, Graham Samuel via use-livecode 
>  wrote:
> 
> Thanks Peter
> 
> It’s encouraging to know about the re-configuring. When I first thought of my 
> project, some years ago, I could not get any sensible response out of the 
> original publisher, and eventually gave up, but now I am thinking of reviving 
> the idea. I think sadly the copyright holder of the CD-ROM is the actual book 
> publisher, which means I will have to re-do the weary round of trying to get 
> them to respond. I have an ancient Mac running OS 7 I believe, just to enable 
> me to look at the CD-ROM in its original form. Better do something before it 
> stops working!
> 
> I am interested in the fact that you are re-configuring your CD-ROM material 
> as desktop applications. That was my original idea for my project, but now I 
> wonder if it should be an app, or indeed whether HTML5 would actually work 
> (using LiveCode of course, as you say!). My target audience are probably 
> ordinary folks interested in poetry, and schools. Are your users happy with 
> the desktop solution?
> 
> Hope this isn’t getting too OT.
> 
> Graham
> 
>> On 11 Feb 2020, at 19:26, Peter Bogdanoff via use-livecode 
>>  wrote:
>> 
>> Hi Graham,
>> 
>> It might be easier to track down the copyright holder of the CD-ROM and 
>> offer to re-publish on a different platform. Copyrights on the design of the 
>> program/disc itself will definitely apply for a long time.
>> 
>> We are re-configuring some of our earlier work HC into LiveCode as desktop 
>> applications. Some things can be, of course, done in as HTML 5. Copyright is 
>> always an issue, especially for licensed, recorded music.
>> 
>> There is obviously a quite large body of great-quality CD-ROM content discs 
>> from the 1990-2000s that have slipped into the dustbin of history—no longer 
>> compatible with digital content delivery methods today—with no easy path to 
>> their revival. Authors and companies have moved on, licensing has expired, 
>> original files used to create the stuff are on old media (Zip drives) or 
>> have disappeared. But with effort, it can be done, and in LiveCode, of 
>> course!
>> 
>> Peter Bogdanoff
>> ArtsInteractive
>> 
>>> On Feb 11, 2020, at 12:58 PM, Graham Samuel via use-livecode 
>>>  wrote:
>>> 
>>> That’s excellent information - I would still have to tackle any missed out 
>>> (obviously I haven’t checked yet) and presumably all the recordings of the 
>>> poet speaking which are much more recent than the composition dates (though 
>>> I don’t understand US copyright laws). And there’s Richard Wilbur’s essay… 
>>> (sigh). Would what one might call the “production design” of a CD-ROM (the 
>>> look, the graphics, the order of presentation etc) be subject to copyright? 
>>> I suppose it’s intellectual property. Sorry, this is getting OT.
>>> 
>>> Graham
>>> 
 On 11 Feb 2020, at 15:49, dev via use-livecode 
  wrote:
 
 https://publicdomain4u.com/as-of-january-1-2019-these-robert-frost-poems-are-public-domain/
 
 
> On Feb 11, 2020, at 2:56 AM, Graham Samuel via use-livecode 
>  wrote:
> 
> Personally I have a pet project to re-purpose a very elaborate CD-ROM 
> about Robert Frost, published by Henry Holt in 1997, but I can never get 
> anyone to talk to me about the copyright issues.
 
 ___
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your 
 subscription preferences:
 http://lists.runrev.com/mailman/listinfo/use-livecode
>>> 
>>> 
>>> ___
>>> use-livecode mailing list
>>> use-livecode@lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and man

Re: Synchronisation of sound and vision

[Devin Asay via use-livecode]

Graham,

Take a look at the duration and the timeScale properties of player objects. By 
dividing duration by timeScale you get the length of the video in seconds.


put the duration of player  “foo” / the timescale of player  “foo” into 
totalSeconds

What you are contemplating is very doable, but you’ll have to do a fair amount 
of work to do to get the synching right. You can take one of several approaches:

- Calculate times as above to predict when to show/highlight the next line. Can 
be tricky with long video files and rounding errors.

- Check the currentTime property of the player to determine the startTime and 
endTime of each spoken line, and set the playSelection of the player to true. 
When the played segment ends, immediately load the following start and end 
times and play again. Something like this, from memory:

set the startTime of player “foo” to 444
set the endTime of player “foo” to 999
set the currentTime of player “foo” to the startTime of player “foo”
set the playerSelection of player “foo” to true
start player “foo"
- Break up the video or audio file into separate files, one line per file, then 
play each succeeding file when the previous one reaches its end. The 
playStopped message is your friend here.

Like I said, it’s doable, but takes a bit of thought and planning, creating 
segment indexes, that sort of thing.

Hope this helps.

Devin


On Feb 12, 2020, at 5:28 AM, Graham Samuel via use-livecode 
mailto:use-livecode@lists.runrev.com>> wrote:

Thanks, that’s a start - I will look at the dictionary. I suppose the callbacks 
rely on one analysing how long each line/word takes the performer to say. It’s 
a lot of work, but there’s no way around it since potentially every line takes 
a different length of time to recite. If it’s too much work, I guess I can just 
display the whole text and have one callback at the end of each recording. 
Maybe that is really the practical solution for a large body of work (say all 
the Shakespeare sonnets, for example).

Anyway thanks for the hint.

Graham

On 12 Feb 2020, at 12:16, Tore Nilsen via use-livecode 
mailto:use-livecode@lists.runrev.com>> wrote:

You will have to use the callbacks property of the player to do what you want 
to do. The callbacks list would be your cues. From the dictionary:

The callbacks of a player <> is a list of callbacks, one per line. Each 
callback consists of an interval number, a comma, and a message <> name.


Regards
Tore Nilsen


12. feb. 2020 kl. 11:25 skrev Graham Samuel via use-livecode 
mailto:use-livecode@lists.runrev.com>>:

Folks, forgive my ignorance, but it’s a long time since I considered the 
following and wondered what pitfalls there are.

I have in mind a project where a recording of someone reading a poetry text 
(“old fashioned” poetry in metrical lines) needs to be synchronised to the 
display text itself on the screen, ideally so that a cursor or highlight would 
move from word to word with the speaker, although that would almost certainly 
involve too much work for the developer (me), or at least highlight lines as 
they are being spoken. I see that one would inevitably have to add cues to the 
spoken text file to fire off the highlighting, which is indeed an unavoidable 
amount of work, but can it be done at all in LC? For example, what form would 
the cues take?

TIA

Graham
___


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Devin Asay
Director
Office of Digital Humanities
Brigham Young University

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Synchronisation of sound and vision

[Tore Nilsen via use-livecode]

Yes, you have to manually set the callbacks. I would opt for lines rather than 
words. You get the callback points by getting the currentTime property from the 
player. If you start at the beginning you can set the first item of the first 
line of the callbacks to: 0. Then you can set a callback for each line in the 
poem by pausing the player after each line and get the currentTime of the 
player. This could be semi automated with a script that is triggered each time 
you pause the player, I guess.

Regards
Tore
 

> 12. feb. 2020 kl. 13:28 skrev Graham Samuel via use-livecode 
> :
> 
> Thanks, that’s a start - I will look at the dictionary. I suppose the 
> callbacks rely on one analysing how long each line/word takes the performer 
> to say. It’s a lot of work, but there’s no way around it since potentially 
> every line takes a different length of time to recite. If it’s too much work, 
> I guess I can just display the whole text and have one callback at the end of 
> each recording. Maybe that is really the practical solution for a large body 
> of work (say all the Shakespeare sonnets, for example).
> 
> Anyway thanks for the hint.
> 
> Graham
> 
>> On 12 Feb 2020, at 12:16, Tore Nilsen via use-livecode 
>>  wrote:
>> 
>> You will have to use the callbacks property of the player to do what you 
>> want to do. The callbacks list would be your cues. From the dictionary:
>> 
>> The callbacks of a player <> is a list of callbacks, one per line. Each 
>> callback consists of an interval number, a comma, and a message <> name. 
>> 
>> 
>> Regards 
>> Tore Nilsen
>> 
>> 
>>> 12. feb. 2020 kl. 11:25 skrev Graham Samuel via use-livecode 
>>> :
>>> 
>>> Folks, forgive my ignorance, but it’s a long time since I considered the 
>>> following and wondered what pitfalls there are.
>>> 
>>> I have in mind a project where a recording of someone reading a poetry text 
>>> (“old fashioned” poetry in metrical lines) needs to be synchronised to the 
>>> display text itself on the screen, ideally so that a cursor or highlight 
>>> would move from word to word with the speaker, although that would almost 
>>> certainly involve too much work for the developer (me), or at least 
>>> highlight lines as they are being spoken. I see that one would inevitably 
>>> have to add cues to the spoken text file to fire off the highlighting, 
>>> which is indeed an unavoidable amount of work, but can it be done at all in 
>>> LC? For example, what form would the cues take?
>>> 
>>> TIA
>>> 
>>> Graham
>>> ___
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com 
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode 
> 
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Synchronisation of sound and vision

[Alex Tweedly via use-livecode]

It shouldn't be that much work (!? he said, in the comfort of knowing he 
won't be doing it :-), at least for lines. Individual words could be too 
hard.


Write a little app, so you can listen to the recording and click a 
button at the start (or end?) of each line, and just keep track of the 
times vs lines that way. Add in the ability to take up from an existing 
position, and with a little bit of manual editing you should be nearly 
there.


Of course, if you (or your helpers) are making the recordings, then you 
can capture the button clicks at the same time as the recording is being 
made.


Alex.

On 12/02/2020 12:28, Graham Samuel via use-livecode wrote:

Thanks, that’s a start - I will look at the dictionary. I suppose the callbacks 
rely on one analysing how long each line/word takes the performer to say. It’s 
a lot of work, but there’s no way around it since potentially every line takes 
a different length of time to recite. If it’s too much work, I guess I can just 
display the whole text and have one callback at the end of each recording. 
Maybe that is really the practical solution for a large body of work (say all 
the Shakespeare sonnets, for example).

Anyway thanks for the hint.

Graham


On 12 Feb 2020, at 12:16, Tore Nilsen via use-livecode 
 wrote:

You will have to use the callbacks property of the player to do what you want 
to do. The callbacks list would be your cues. From the dictionary:

The callbacks of a player <> is a list of callbacks, one per line. Each callback 
consists of an interval number, a comma, and a message <> name.


Regards
Tore Nilsen



12. feb. 2020 kl. 11:25 skrev Graham Samuel via use-livecode 
:

Folks, forgive my ignorance, but it’s a long time since I considered the 
following and wondered what pitfalls there are.

I have in mind a project where a recording of someone reading a poetry text 
(“old fashioned” poetry in metrical lines) needs to be synchronised to the 
display text itself on the screen, ideally so that a cursor or highlight would 
move from word to word with the speaker, although that would almost certainly 
involve too much work for the developer (me), or at least highlight lines as 
they are being spoken. I see that one would inevitably have to add cues to the 
spoken text file to fire off the highlighting, which is indeed an unavoidable 
amount of work, but can it be done at all in LC? For example, what form would 
the cues take?

TIA

Graham
___


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Synchronisation of sound and vision

[Graham Samuel via use-livecode]

Thanks, that’s a start - I will look at the dictionary. I suppose the callbacks 
rely on one analysing how long each line/word takes the performer to say. It’s 
a lot of work, but there’s no way around it since potentially every line takes 
a different length of time to recite. If it’s too much work, I guess I can just 
display the whole text and have one callback at the end of each recording. 
Maybe that is really the practical solution for a large body of work (say all 
the Shakespeare sonnets, for example).

Anyway thanks for the hint.

Graham

> On 12 Feb 2020, at 12:16, Tore Nilsen via use-livecode 
>  wrote:
> 
> You will have to use the callbacks property of the player to do what you want 
> to do. The callbacks list would be your cues. From the dictionary:
> 
> The callbacks of a player <> is a list of callbacks, one per line. Each 
> callback consists of an interval number, a comma, and a message <> name. 
> 
> 
> Regards 
> Tore Nilsen
> 
> 
>> 12. feb. 2020 kl. 11:25 skrev Graham Samuel via use-livecode 
>> :
>> 
>> Folks, forgive my ignorance, but it’s a long time since I considered the 
>> following and wondered what pitfalls there are.
>> 
>> I have in mind a project where a recording of someone reading a poetry text 
>> (“old fashioned” poetry in metrical lines) needs to be synchronised to the 
>> display text itself on the screen, ideally so that a cursor or highlight 
>> would move from word to word with the speaker, although that would almost 
>> certainly involve too much work for the developer (me), or at least 
>> highlight lines as they are being spoken. I see that one would inevitably 
>> have to add cues to the spoken text file to fire off the highlighting, which 
>> is indeed an unavoidable amount of work, but can it be done at all in LC? 
>> For example, what form would the cues take?
>> 
>> TIA
>> 
>> Graham
>> ___


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Synchronisation of sound and vision

[Tore Nilsen via use-livecode]

You will have to use the callbacks property of the player to do what you want 
to do. The callbacks list would be your cues. From the dictionary:

The callbacks of a player <> is a list of callbacks, one per line. Each 
callback consists of an interval number, a comma, and a message <> name. 


Regards 
Tore Nilsen


> 12. feb. 2020 kl. 11:25 skrev Graham Samuel via use-livecode 
> :
> 
> Folks, forgive my ignorance, but it’s a long time since I considered the 
> following and wondered what pitfalls there are.
> 
> I have in mind a project where a recording of someone reading a poetry text 
> (“old fashioned” poetry in metrical lines) needs to be synchronised to the 
> display text itself on the screen, ideally so that a cursor or highlight 
> would move from word to word with the speaker, although that would almost 
> certainly involve too much work for the developer (me), or at least highlight 
> lines as they are being spoken. I see that one would inevitably have to add 
> cues to the spoken text file to fire off the highlighting, which is indeed an 
> unavoidable amount of work, but can it be done at all in LC? For example, 
> what form would the cues take?
> 
> TIA
> 
> Graham
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Synchronisation of sound and vision

[Graham Samuel via use-livecode]

Folks, forgive my ignorance, but it’s a long time since I considered the 
following and wondered what pitfalls there are.

I have in mind a project where a recording of someone reading a poetry text 
(“old fashioned” poetry in metrical lines) needs to be synchronised to the 
display text itself on the screen, ideally so that a cursor or highlight would 
move from word to word with the speaker, although that would almost certainly 
involve too much work for the developer (me), or at least highlight lines as 
they are being spoken. I see that one would inevitably have to add cues to the 
spoken text file to fire off the highlighting, which is indeed an unavoidable 
amount of work, but can it be done at all in LC? For example, what form would 
the cues take?

TIA

Graham
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: HyperCard: the Myst story

[Graham Samuel via use-livecode]

Thanks Peter

It’s encouraging to know about the re-configuring. When I first thought of my 
project, some years ago, I could not get any sensible response out of the 
original publisher, and eventually gave up, but now I am thinking of reviving 
the idea. I think sadly the copyright holder of the CD-ROM is the actual book 
publisher, which means I will have to re-do the weary round of trying to get 
them to respond. I have an ancient Mac running OS 7 I believe, just to enable 
me to look at the CD-ROM in its original form. Better do something before it 
stops working!

I am interested in the fact that you are re-configuring your CD-ROM material as 
desktop applications. That was my original idea for my project, but now I 
wonder if it should be an app, or indeed whether HTML5 would actually work 
(using LiveCode of course, as you say!). My target audience are probably 
ordinary folks interested in poetry, and schools. Are your users happy with the 
desktop solution?

Hope this isn’t getting too OT.

Graham

> On 11 Feb 2020, at 19:26, Peter Bogdanoff via use-livecode 
>  wrote:
> 
> Hi Graham,
> 
> It might be easier to track down the copyright holder of the CD-ROM and offer 
> to re-publish on a different platform. Copyrights on the design of the 
> program/disc itself will definitely apply for a long time.
> 
> We are re-configuring some of our earlier work HC into LiveCode as desktop 
> applications. Some things can be, of course, done in as HTML 5. Copyright is 
> always an issue, especially for licensed, recorded music.
> 
> There is obviously a quite large body of great-quality CD-ROM content discs 
> from the 1990-2000s that have slipped into the dustbin of history—no longer 
> compatible with digital content delivery methods today—with no easy path to 
> their revival. Authors and companies have moved on, licensing has expired, 
> original files used to create the stuff are on old media (Zip drives) or have 
> disappeared. But with effort, it can be done, and in LiveCode, of course!
> 
> Peter Bogdanoff
> ArtsInteractive
> 
>> On Feb 11, 2020, at 12:58 PM, Graham Samuel via use-livecode 
>>  wrote:
>> 
>> That’s excellent information - I would still have to tackle any missed out 
>> (obviously I haven’t checked yet) and presumably all the recordings of the 
>> poet speaking which are much more recent than the composition dates (though 
>> I don’t understand US copyright laws). And there’s Richard Wilbur’s essay… 
>> (sigh). Would what one might call the “production design” of a CD-ROM (the 
>> look, the graphics, the order of presentation etc) be subject to copyright? 
>> I suppose it’s intellectual property. Sorry, this is getting OT.
>> 
>> Graham
>> 
>>> On 11 Feb 2020, at 15:49, dev via use-livecode 
>>>  wrote:
>>> 
>>> https://publicdomain4u.com/as-of-january-1-2019-these-robert-frost-poems-are-public-domain/
>>> 
>>> 
 On Feb 11, 2020, at 2:56 AM, Graham Samuel via use-livecode 
  wrote:
 
 Personally I have a pet project to re-purpose a very elaborate CD-ROM 
 about Robert Frost, published by Henry Holt in 1997, but I can never get 
 anyone to talk to me about the copyright issues.
>>> 
>>> ___
>>> use-livecode mailing list
>>> use-livecode@lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your 
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> 
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode