To go back to the bugs for a moment, I'm seeing an issue with the
PulseAudio abstraction on Linux. The player context does not seem to be
created with the throw-away Player (from source.play()). I took a quick
peek at the code, and it seems that self.context is still set to None at
the point of the crash. In the code below, "note_wave" is just a static
source. I haven't yet dug into it further. Could any other Linux users
confirm? I'm using the "examples/synthesizer.py" example to test.
File "synthesizer.py", line 63, in play_note
note_wave.play()
File
"/home/ben/Documents/PycharmProjects/pyglet/pyglet/media/sources/base.py",
line 275, in play
player.play()
File "/home/ben/Documents/PycharmProjects/pyglet/pyglet/media/player.py",
line 238, in play
self._set_playing(True)
File "/home/ben/Documents/PycharmProjects/pyglet/pyglet/media/player.py",
line 190, in _set_playing
self._create_audio_player()
File "/home/ben/Documents/PycharmProjects/pyglet/pyglet/media/player.py",
line 342, in _create_audio_player
setattr(self, attr, value)
File "/home/ben/Documents/PycharmProjects/pyglet/pyglet/media/player.py",
line 124, in __set__
getattr(obj._audio_player, 'set_' + self.attribute)(value)
File
"/home/ben/Documents/PycharmProjects/pyglet/pyglet/media/drivers/pulse/adaptation.py"
, line 418, in set_volume
with self.context:
AttributeError: __enter__
On Monday, November 27, 2017 at 6:55:16 AM UTC+9, Greg Ewing wrote:
>
> Daniel Gillet wrote:
> > If playlists are iterators, it means that
> > player.queue takes as an argument an iterator. But player.queue(song)
> > does not qualify anymore, as song is a Source and not an iterator.
>
> There are a couple of ways to handle that. One is to have
> player.queue() inspect its argument and do different things
> depending on whether it's a Source instance or not.
>
> Another is to have two methods, such as player.queue_source()
> and player.queue_playlist().
>
> There are pros and cons either way. The single method is
> less to remember and maybe slightly easier to document,
> but two separate methods is friendlier towards duck-typing
> and makes the intent of the code clearer to the reader.
>
> I'll leave it up to you to decide.
>
> > player.queue(song1)
> > player.queue(song2)
> >
> > The user would probably expect that the songs are all played once and
> > then the player stops once all the songs have been played.
> >
> > Does this mean that the Player has some sort of default PlayList which
> > would be similar to a list where queuing songs mean you're appending
> > them to the list? And obviously the Player would then get an iterator
> > from that list. If on the other hand the client code provides an
> > iterator to the player.queue method, then we just use that one to get
> > the Sources.
>
> I don't think that's quite right. If the user does this:
>
> player.queue(song1)
> player.queue(some_iterator)
> player.queue(song2)
>
> it should play song1, then all the songs returned by the
> iterator, then song2.
>
> I think what you need is an internal list of "things to be
> played", each of which can be either a Source or an iterator,
> and have it work its way through that.
>
> If it would make anything simpler, you could wrap a single
> Source in a one-element sequence before putting it in the
> list, so that all the things in the list are iterables.
>
> --
> Greg
>
--
You received this message because you are subscribed to the Google Groups
"pyglet-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/pyglet-users.
For more options, visit https://groups.google.com/d/optout.
