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 > <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 >> <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 >> <use-livecode@lists.runrev.com<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 >> <use-livecode@lists.runrev.com<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 >> <use-livecode@lists.runrev.com<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<mailto: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 > > > _______________________________________________ > 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
