On Mon, 28 May 2018 11:07:31 -0400
Yoni Rabkin wrote:
> Mike Kazantsev writes:
>
> > Please let me know if it's gotten better or worse this way.
>
> The new indentation seems fine to me since it's what Emacs produces by
> default with indent-region. There were two lines that didn't get
> inden
Mike Kazantsev writes:
> On Sat, 26 May 2018 03:36:34 +0500
> Mike Kazantsev wrote:
>
>> On Fri, 25 May 2018 18:25:13 -0400
>> Yoni Rabkin wrote:
>>
>> > At least I'm not asking you to modify your idiosyncratic
>> > indentation. Now _that's_ a red line I wouldn't ask anyone to cross.
>>
>>
On Sat, 26 May 2018 03:36:34 +0500
Mike Kazantsev wrote:
> On Fri, 25 May 2018 18:25:13 -0400
> Yoni Rabkin wrote:
>
> > At least I'm not asking you to modify your idiosyncratic
> > indentation. Now _that's_ a red line I wouldn't ask anyone to cross.
>
> It's some kind of auto-indenter that
On Sat, 26 May 2018 04:21:46 +0500
Mike Kazantsev wrote:
> On Sat, 26 May 2018 04:14:52 +0500
> Mike Kazantsev wrote:
>
> > On Fri, 25 May 2018 18:59:06 -0400
> > Yoni Rabkin wrote:
> >
> > > Another change needed is to add a regexp to the player so that
> > > (emms-player-get emms-player-m
On Sun, 27 May 2018 22:20:30 -0400
Yoni Rabkin wrote:
> Mike Kazantsev writes:
>
> > On Sat, 26 May 2018 01:42:47 +0200
> > Pierre Neidhardt wrote:
> >
> >> Yoni Rabkin writes:
> >>
> >> > None that I can think of, unless we move to emms-plr-... or
> >> > something, which isn't a huge im
Mike Kazantsev writes:
> On Sat, 26 May 2018 01:42:47 +0200
> Pierre Neidhardt wrote:
>
>> Yoni Rabkin writes:
>>
>> > None that I can think of, unless we move to emms-plr-... or
>> > something, which isn't a huge improvement; I think that players
>> > should have their own namespace.
>> >
>>
On Sat, 26 May 2018 01:42:47 +0200
Pierre Neidhardt wrote:
> Yoni Rabkin writes:
>
> > None that I can think of, unless we move to emms-plr-... or
> > something, which isn't a huge improvement; I think that players
> > should have their own namespace.
> >
> > I've always kind of visually "tuned
Yoni Rabkin writes:
> None that I can think of, unless we move to emms-plr-... or something,
> which isn't a huge improvement; I think that players should have their
> own namespace.
>
> I've always kind of visually "tuned out" the long names. I guess I could
> also write up some code to abbrevi
On Sat, 26 May 2018 04:14:52 +0500
Mike Kazantsev wrote:
> On Fri, 25 May 2018 18:59:06 -0400
> Yoni Rabkin wrote:
>
> > Another change needed is to add a regexp to the player so that
> > (emms-player-get emms-player-mpv 'regex) will return a useful value that
> > emms-source-file-regex can use
On Fri, 25 May 2018 18:59:06 -0400
Yoni Rabkin wrote:
> Another change needed is to add a regexp to the player so that
> (emms-player-get emms-player-mpv 'regex) will return a useful value that
> emms-source-file-regex can use.
>
> Among other things this breaks is that the various
> emms-add-..
Mike Kazantsev writes:
> On Fri, 25 May 2018 16:02:10 -0400
> Yoni Rabkin wrote:
>
>> Before you do, please change the dependence on the cl package to the
>> newer cl-lib (clean namespace), and make sure that emms-mpv-ipc-proc is
>> defined before it is referenced.
>
> Oh, right, forgot to check
On Fri, 25 May 2018 18:22:59 -0400
Yoni Rabkin wrote:
> Mike Kazantsev writes:
>
> > On Fri, 25 May 2018 17:55:56 -0400
> > Yoni Rabkin wrote:
> >
> >> I also think the code needs to move to the emms-player-... namespace.
> >
> > Yeah, I was kinda afraid of that.
> >
> > Not hard to change
(sorry for duplicate, mailed it off-list accidentally)
On Fri, 25 May 2018 18:25:13 -0400
Yoni Rabkin wrote:
> Mike Kazantsev writes:
>
> > On Fri, 25 May 2018 17:55:56 -0400
> > Yoni Rabkin wrote:
> >
> >> I also think the code needs to move to the emms-player-... namespace.
> >
> > Yeah
Mike Kazantsev writes:
> On Fri, 25 May 2018 17:55:56 -0400
> Yoni Rabkin wrote:
>
>> I also think the code needs to move to the emms-player-... namespace.
>
> Yeah, I was kinda afraid of that.
At least I'm not asking you to modify your idiosyncratic
indentation. Now _that's_ a red line I would
Mike Kazantsev writes:
> On Fri, 25 May 2018 17:55:56 -0400
> Yoni Rabkin wrote:
>
>> I also think the code needs to move to the emms-player-... namespace.
>
> Yeah, I was kinda afraid of that.
>
> Not hard to change, but that'd make all the names so horribly long,
> hurting readability, unless
On Sat, 26 May 2018 03:06:54 +0500
Mike Kazantsev wrote:
> On Fri, 25 May 2018 17:55:56 -0400
> Yoni Rabkin wrote:
>
> > Using the file method it doesn't detect the player ending and
> > therefore doesn't move on to the next track. This had worked before,
> > so I'm unsure of what changed.
>
On Fri, 25 May 2018 17:55:56 -0400
Yoni Rabkin wrote:
> I also think the code needs to move to the emms-player-... namespace.
Yeah, I was kinda afraid of that.
Not hard to change, but that'd make all the names so horribly long,
hurting readability, unless there some way to filter all that noise
On Fri, 25 May 2018 17:44:08 -0400
Yoni Rabkin wrote:
> I use Emms to play long videos often and would like to integrate
> bookmarking with the ability to detect when and where the video had been
> paused on the mpv side (someone walked into the room and hit the
> space-bar on my machine in order
Mike Kazantsev writes:
> On Fri, 25 May 2018 16:02:10 -0400
> Yoni Rabkin wrote:
>
>> Before you do, please change the dependence on the cl package to the
>> newer cl-lib (clean namespace), and make sure that emms-mpv-ipc-proc is
>> defined before it is referenced.
>
> Oh, right, forgot to check
Mike Kazantsev writes:
> On Fri, 25 May 2018 16:02:10 -0400
> Yoni Rabkin wrote:
>
>> Before you do, please change the dependence on the cl package to the
>> newer cl-lib (clean namespace), and make sure that emms-mpv-ipc-proc is
>> defined before it is referenced.
>
> Oh, right, forgot to check
On Fri, 25 May 2018 16:02:10 -0400
Yoni Rabkin wrote:
> Before you do, please change the dependence on the cl package to the
> newer cl-lib (clean namespace), and make sure that emms-mpv-ipc-proc is
> defined before it is referenced.
Oh, right, forgot to check it for warnings after updates, fixe
Mike Kazantsev writes:
> On Mon, 16 Apr 2018 01:00:17 +0500
> Mike Kazantsev wrote:
>
>> Pushed new backend option now to mpv-json-ipc branch, with support for
>> both older mpv versions with one-pid-per-track + --input-file operation
>> and newer versions running as "mpv --idle".
>>
>> Tried t
This is great! Thanks for the update.
I'll review the code as soon as possible.
It's been working well for me so far.
> Don't think I should have access to master branch, but if you want me
> to merge/push it there myself, can easily do that.
Yoni, what do you think? :)
--
Pierre Neidhardt
On Mon, 16 Apr 2018 01:00:17 +0500
Mike Kazantsev wrote:
> Pushed new backend option now to mpv-json-ipc branch, with support for
> both older mpv versions with one-pid-per-track + --input-file operation
> and newer versions running as "mpv --idle".
>
> Tried to address all the feedback and sugg
Thanks for all the tips, that's very helpful.
After further testing, I don't think this has anything to do with Emms.
I use GuixSD and I experience strange behaviour when I re-log to my
session: pulseaudio is started multiple times.
--
Pierre Neidhardt
As President I have to go vacuum my coin
On Sun, 22 Apr 2018 14:44:30 +0530
Pierre Neidhardt wrote:
> I've noticed another issue: with mpv constantly running, it keeps
> pulseaudio always up and seems to prevent power management on the audio
> card.
>
> I'm not sure about the details but a consequence of switching to Mike's
> implement
I've noticed another issue: with mpv constantly running, it keeps
pulseaudio always up and seems to prevent power management on the audio
card.
I'm not sure about the details but a consequence of switching to Mike's
implementation of the mpv backed has resulted in a 25% drop in battery
life.
I'm
Sorry for the lack of info, I have very little time at the moment.
I'll come back to this later, just bump me if I forget.
--
Pierre Neidhardt
The more they over-think the plumbing the easier it is to stop up the drain.
signature.asc
Description: PGP signature
On Wed, 18 Apr 2018 11:50:25 +0530
Pierre Neidhardt wrote:
> Mike Kazantsev writes:
>
> > Fixed in last commit by always removing paused state in
> > emms-player-start, which seem to make perfect sense there.
>
> OK, seems to work fine so far. I'll have a look at code later when I
> have mo
Mike Kazantsev writes:
> Fixed in last commit by always removing paused state in
> emms-player-start, which seem to make perfect sense there.
OK, seems to work fine so far. I'll have a look at code later when I
have more time.
Yoni?
--
Pierre Neidhardt
Gloffing is a state of mine.
signat
On Tue, 17 Apr 2018 20:26:49 +0500
Mike Kazantsev wrote:
> I think this situation is indeed a bug, as guess emms-next should
> also unpause the track, or at least not reset emms-player-paused-p if
> it doesn't - will fix in a moment, haven't considered what should
> happen on pause+switch like th
On Tue, 17 Apr 2018 17:24:38 +0530
Pierre Neidhardt wrote:
> From which state do you expect this?
I thought you'd run it from scratch, with all the requires and init
stuff in there, so that everything that mpv instance does will be
captured, assuming that issue happens there, of course.
But any
Mike Kazantsev writes:
> Can you do:
>
> (require 'emms-player-mpv)
> (add-to-list 'emms-player-list 'emms-player-mpv)
> (setq emms-mpv-debug t)
> (emms-player-mpv-start (emms-playlist-current-selected-track))
From which state do you expect this? Anyways, here is a message when I
ran t
On Mon, 16 Apr 2018 12:03:26 +0500
Mike Kazantsev wrote:
> On Mon, 16 Apr 2018 11:11:41 +0530
> Pierre Neidhardt wrote:
>
> > Well, did not take long! :p
> > - Seeking forward / backward resets the timer (but the seeking works).
Was due to issuing emms-player-started on every playback-res
On Mon, 16 Apr 2018 11:11:41 +0530
Pierre Neidhardt wrote:
> Well, did not take long! :p
Oh well, not entirely unexpected :)
> - When I first started playing, I could not hear anything. I had to
> pause/unpause so that mpv would start make sounds.
Suspect this one is due to mpv configuration
Well, did not take long! :p
- When I first started playing, I could not hear anything. I had to
pause/unpause so that mpv would start make sounds.
- Seeking forward / backward resets the timer (but the seeking works).
--
Pierre Neidhardt
Paul Revere was a tattle-tale.
signature.asc
Descrip
Wow, great work! I'll keep running your branch for now and report if I
run into any issue.
Thanks again!
--
Pierre Neidhardt
signature.asc
Description: PGP signature
___
Emms-help mailing list
Emms-help@gnu.org
https://lists.gnu.org/mailman/listinf
On Sat, 14 Apr 2018 00:48:43 +0500
Mike Kazantsev wrote:
> On Fri, 13 Apr 2018 15:31:23 -0400
> Yoni Rabkin wrote:
>
> > I have version 0.3.4 of mpv on my machine (Trisquel) so this code
> > wouldn't work on my box. I think one needs (<= 0.17.0 mpv-version). We'd
> > need a way not to break mpv
Ian Dunn writes:
> A brief pass of Mike's code looks like he's using a persistent mpv
> instance (via the --idle flag), whereas momomo5717's version spawns
> and destroys a new one with each new track. Mpv supports both
> methods, so I think a persistent instance would be the way to go.
Sounds
On Fri, 13 Apr 2018 15:31:23 -0400
Yoni Rabkin wrote:
> I have version 0.3.4 of mpv on my machine (Trisquel) so this code
> wouldn't work on my box. I think one needs (<= 0.17.0 mpv-version). We'd
> need a way not to break mpv for people who start enjoying it in 5.0.
Right.
Guess I'll look for
On Fri, 13 Apr 2018 15:23:05 -0400
Ian Dunn wrote:
> 1a. You should require s and dash in the header, as they both appear to be
> dependencies. I can't immediately see any others.
> 1b. Neither is currently a dependency of EMMS, so either they'd have to be
> added, or removed from your code.
>
I have version 0.3.4 of mpv on my machine (Trisquel) so this code
wouldn't work on my box. I think one needs (<= 0.17.0 mpv-version). We'd
need a way not to break mpv for people who start enjoying it in 5.0.
Mike Kazantsev writes:
> Not sure on coding style strictness, tabs-spaces and such, bu
MK> Hi,
MK> Have been using recently-merged dochang/emms-player-mpv emms backend for
MK> a while, but recently had an thought to get track durations from mpv, as
MK> pre-scanning them otherwise from mostly-sshfs sources is quite slow.
MK> So implemented a different backend f
On Sat, 14 Apr 2018 00:00:14 +0500
Mike Kazantsev wrote:
> On Fri, 13 Apr 2018 21:53:47 +0530
> Pierre Neidhardt wrote:
>
> > It turned out that there were many rough edges that needed polishing
> > before merging. So instead we opted for dochang's simpler version for
> > now and we will adopt
PN> I haven't looked at your code, but isn't it duplicating momomo5717's
PN> effort?
A brief pass of Mike's code looks like he's using a persistent mpv instance
(via the --idle flag), whereas momomo5717's version spawns and destroys a new
one with each new track. Mpv supports both meth
On Fri, 13 Apr 2018 14:44:49 -0400
Yoni Rabkin wrote:
> Thank you for the offer. Having the bi-directional communication would
> be good. For the 5.0 release on the 1st of May we will keep the current
> implementation since it Just Works (TM). After the release I have no
> problem with adding API
On Fri, 13 Apr 2018 21:53:47 +0530
Pierre Neidhardt wrote:
> Thanks for the hard work!
>
> Before merging dochang/emms-player-mpv, we also considered
> https://github.com/momomo5717/emms-player-simple-mpv which uses IPC as
> well.
>
> It turned out that there were many rough edges that needed p
Thank you for the offer. Having the bi-directional communication would
be good. For the 5.0 release on the 1st of May we will keep the current
implementation since it Just Works (TM). After the release I have no
problem with adding API features galore.
Do you want to be the one working on this?
Thanks for the hard work!
Before merging dochang/emms-player-mpv, we also considered
https://github.com/momomo5717/emms-player-simple-mpv which uses IPC as
well.
It turned out that there were many rough edges that needed polishing
before merging. So instead we opted for dochang's simpler versio
Hi,
Have been using recently-merged dochang/emms-player-mpv emms backend
for a while, but recently had an thought to get track durations from
mpv, as pre-scanning them otherwise from mostly-sshfs sources is quite
slow.
So implemented a different backend for mpv using its bidirectional
"JSON IPC"
50 matches
Mail list logo
