== Meeting information == * #ubuntu-touch-meeting: Music meeting, 14 Aug at 19:30 — 20:22 UTC * Full logs at [[http://ubottu.com/meetingology/logs/ubuntu-touch-meeting/2015/ubuntu-touch-meeting.2015-08-14-19.30.log.html]] == Meeting summary == ''LINK:'' https://github.com/Elleo/libQtSpotify ''LINK:'' http://people.canonical.com/~alan/screenshots/device-2015-08-14-205651.png ''LINK:'' https://docs.google.com/file/d/0B3XynHVKfrvMejVpQVhUd1J3ZWM/edit ? ''LINK:'' https://developer.ubuntu.com/en/blog/2015/08/10/adaptive-page-layouts/ == Vote results == == Done items == * (none) == People present (lines said) == * ahayzen (137) * popey (116) * vthompson (68) * meetingology (3) == Full Log == 19:30 #startmeeting Music meeting 19:30 Meeting started Fri Aug 14 19:30:40 2015 UTC. The chair is popey. Information about MeetBot at http://wiki.ubuntu.com/meetingology. 19:30 19:30 Available commands: action commands idea info link nick 19:31 sup folks ? vthompson popey o/ 19:31 Glad it's friday 19:31 \o/ 19:31 Woohoo! But it's too hot to go outside here, ha 19:31 :) 19:31 Hide in your cave. 19:31 hot? its been trying to rain all day :-/ 19:31 It succeeded here. 19:32 ...so whats happened since last week ;-) 19:32 ahayzen: so that music app wishlist, i think maybe it needs updating :) 19:32 that list we said we would make sortof got sidelined post that email 19:32 I think the topics of discussion are the same as they were last week. 1) convergence and 2) mh3 bg playlists 19:33 also... nik90 reported this which i'm gonna try and do next week in my week off me thinks https://bugs.launchpad.net/music-app/+bug/1483911 19:33 Well, I would like for you guys to be able to chat with the people pushing streaming media. 19:33 (it was a dup of another) 19:33 ok 19:33 yeah i think we firstly need to figure out ... what in a perfect world would the designers want? 19:33 Agreed, it's hard to meet during the week for me--that's why I pushed for us to meet today 19:34 then .. what is technical possible... then what can we do in the next timeframe 19:34 The general take away was that we should _consider_ the following:-0 19:34 1) Add streaming support to existing music app as an almost entirely separate set of functionality from the existing local playback 19:35 i.e. not integrate remote & local playlists for version 1.0 19:35 yup 19:35 2) Add multiple streaming systems, not just one, not just proprietary 19:35 could we send out a poll for the open source one? 19:35 to prove we can, to ensure we're not just about the proprietary systems, and to potentially provide a template for others 19:35 when we have shortlists ones we know we can use their APIs 19:35 That's not a bad idea. 19:36 as i have no idea which is most popular 19:36 I'd like to add multiple as the end result--but I think we'd have to start with one? 19:36 I honestly don't know what "open" streaming services there are 19:36 And I'd assume that'd be a proprietary one 19:36 the ones that used to appear in RB lol 19:36 thats as far as my knowledge goes 19:37 i dont think rb had any by default other than magnatune and jamendo 19:37 and they weren't really streaming, more buy/download like amazon 19:37 does https://www.jamendo.com/en do streaming ? 19:37 ah 19:37 it may, not looked recently 19:38 Wouldn't any streaming service need some sort of plugin with MPRIS support in order to make it useful in Media hub? 19:38 banshee supports amazon (as a store), miro, archive.org and last.fm 19:38 ok just to throw it in the mix...what is the difference between a streaming provider and a radio station ? 19:38 would radio stations be within the scope ? 19:38 stream = choose the song 19:38 radio = broadcast 19:38 but your effectively listening to a 'stream' 19:38 So pandora would be technically radio? But you can skip songs 19:39 I don't know pandora, we don't have it here. 19:39 jim mentioned pandora 19:39 ahayzen: if you want to get picky, sure 19:39 i'm just saying is there any technical reason we could not have radio as well? 19:39 but the spotify's of this world you pick and curate your collection 19:39 A simple stream would be the "easiest" to support as we wouldn't need to do searches, etc 19:39 yeah 19:40 i think a "radio" style stream is very different, and simpler 19:40 generally little navigation, curation. 19:40 But for each service there's probably nuances like searching for particular genres, liking/thumbs upping a song, etc. 19:40 yeah maybe this is a separate discussion ... ok so that was point 2) were there more? 19:40 yes. 19:41 The main point was we'd like to at least investigate the possibility of embedding it in the app 19:41 it tells a better story that we have one app that can support many providers 19:41 than "get this app for that provider, another app for another provider" 19:41 that way is no different from android and ios 19:41 with baking it into one app, we can potentially differentiate 19:41 yes i agree integration would be awesome 19:41 if you only have local music, fine 19:42 One of the problems I have is that there are so many ways/points of integration. If we simply have it as a separate mini-app of sorts inside the music app--I don't think that provides a good user experience 19:42 if you don't want to use "the cloud", fine. 19:42 so would we try and share the now playing/queue pages ? 19:42 and then eventually playlists ? 19:42 I would be fine initially having "local playlists" and "remote playlists" 19:42 i could see sharing the now playing/queue being much easier post bg-playlists being implemented 19:43 I think we should get design to come up with what this "mini app" inside the music app would look like and what features it would provide 19:43 yeah.. 19:43 okay 19:43 i'm thinking like a separate tab for say spotify... 19:43 And also get other people spun up to make sure this is even possible still 19:44 i think they envisaged just a tab like ahayzen says 19:44 then that is just a view to select albums/tracks whatever 19:44 they then get added to the same queue/now playing as local 19:44 trying not to intrusively mess with local playback 19:44 of course for some providers (like spotify) we have platform issues 19:44 ok so how will this work from a security and packaging point of view ? 19:44 like lifecycle, playlist etc 19:45 ahayzen: details... :) 19:45 I wonder if the first go at this should have different queues or if we should straight away integrate both local and remote streams in the Now Playing 19:45 hopefully the spotify decoder can be baked into media-hub 19:45 yeah, I'm not sure where that baking would be 19:45 yeah initally i would say separate queues, separate playlists etc 19:45 then merge them for 2.0 19:45 I'd keep as much separate as possible 19:45 so for example if you _didnt_ sign into $provider, you get the same vanilla experience 19:46 if you _do_ sign into $provider, you get an extra tab/screen or two (settings etc) 19:46 Yea, we probably wouldn't store the proprietary playlists because they are already stored by the remote system 19:46 so from my understanding the http stream has to be decoded before it can hit the pipeline... mh can already play a http stream, so if the decoder was in media-hub as well it could then pass it to the pipeline 19:46 (for spotify) 19:46 Yes, there's challenges for the decoding for spotify specifically 19:46 and maybe for others too, I haven't looked 19:46 yup ok 19:47 So, overall what's the timeframe that Joe etc are looking at for this? 19:47 so these mini apps, will essentially be their own .click/.snap packages that then run inside us ? 19:47 no 19:47 they would be part of music app 19:47 ooooh right 19:47 I think we'd detect a UOA and then expose a separate tab 19:47 but not intrusively having their tentacles all over the app 19:47 i thought they were separate, hence me asking security ;-) 19:47 ah i see 19:47 so if you dont use jamendo you dont see jamendo artifacts in the app 19:48 same for spotify or whatever 19:48 so is the platform going to bundle the UOA ? 19:48 or are we? 19:48 details... 19:48 dunno. 19:48 we could ship the UOA provider 19:48 thats what Reminders (Notes) does 19:48 Well we are on the platform... I'd prefer it be part of the image not our click 19:48 ok right i see now 19:48 evernote UOA is inside the reminders click 19:48 yeah i'd like other apps to be able to make use of the UOA as well 19:48 well yes, true 19:49 we can look into that 19:49 agreed, a third party spotify app should be supported 19:49 but we went the other direction for notes/reminders 19:49 it used to be a deb, we moved to bake it into the app click 19:49 heh :-) 19:49 which means that you have to have that app to get teh UOA 19:49 so as victor said... what timeframes are we talking about ? 19:50 I don't think we have one. 19:50 Well, actually, maybe we should package some of the UOAs what if we support 3 or so different ones? We wouldn't expect the platform to expose them all by default would we? 19:50 there's a lot of moving parts here 19:50 assume we are talking months/quarters not weeks or years 19:50 yes 19:50 cool 19:51 I kinda think we should almost make a separate app/proof of concept with the design of the music app first 19:51 yeah a mini app :') 19:51 lol 19:51 I'd worry that we'd end up using that 19:51 ok a branch off the current app 19:51 and then we fail the "wouldn't it be nice to have it baked in" part :) 19:51 yeah, prefer that 19:51 in which we hack about 19:52 have we had the legal team check that spotify is cool to integrate ? 19:52 cool in what way? 19:52 I suppose. One thing I think needs to be done though is to first make sure CuteSpotify works still 19:52 its apparently cool if we don't call ourselves spotify ? 19:52 and we'd have to bundle that decoder ? 19:52 yes, we have spoken to spotify 19:52 did that only work with paid accounts IIRC ? 19:52 They expose the API after all 19:52 yep, only paid 19:53 we should use libqtspotify 19:53 which abstracts away the spotify library 19:53 yeah :-) 19:53 because spotify are deprecating that and replacing with a new one soon (no timeline) 19:53 * ahayzen senses many /vendor folders appearing 19:53 popey, really, they are deprecating libSpotify? Wouldn't that impact libqtspotify? 19:54 but they are going to replace it? 19:54 yes, libqtspotify would need updating 19:54 (mike sheldon could do that) 19:54 don't they have a desktop app ? 19:54 (he made cute spotify and libqtspotify iirc) 19:54 Ok, or I think he ported it. It was originally from a diferent platform 19:54 yeah, you're right 19:54 he came from n9 days 19:55 :-) 19:55 https://github.com/Elleo/libQtSpotify 19:55 :) 19:55 its got (C) of nokia people from 2011 in it 19:55 he said during the call last week he'd be up for updating it when libspotify gets replaced 19:55 What should we be doing to get this ready? I think we need designs and we need to ensure libQtSpotify and all still work... but what should *we* do? 19:55 cutespotify does work 19:56 therefore libqtspotify and libspotify work 19:56 oh, I thought someone said it wasn't working anymore 19:56 there were ui issues iirc 19:56 * popey tests 19:56 ah 19:56 turn off the screen ;-) 19:56 hehe 19:56 That makes me feel 95% better 19:56 http://people.canonical.com/~alan/screenshots/device-2015-08-14-205651.png 19:57 ok so as victor says i think we need some designs next to then know what we should be doing 19:57 if we also have a look at cutespotify and start a branch of music just seeing if we can play something 19:57 We'd probably need to start a branch that bundles libQtSpotify as a first go? 19:57 yup 19:58 goodbye qml app for now :( 19:58 and it sounds like the homework for us is to generate a list of open source streaming services 19:58 just one will do :) 19:58 for a poll? 19:58 oh i see 19:58 for a poll and then to build along with the spotify one 19:58 i would prefer we build with two at the same time 19:59 We have too many polls queued up ;) 19:59 hah 19:59 i know it'll be a pain but it'll save us in the long run as at least we can be sure we've abstracted enough 19:59 ...maybe we should have a questionnaire... 19:59 It'll depend on the other streaming service.. It'd be nice if it had similar features as the proprietary one... 19:59 yeah exactly hence..research find some candidates 20:00 Good call 20:00 tbh I think if you just ask the question "What music streaming service would you like to see on Ubuntu phone" you'd get a bunch of answers 20:00 Are you volunteering, ahayzen ? :) 20:00 what have i volunteered for? 20:00 popey, good point. Then we could do our research with the support of that list 20:00 and would provide some people +1ing them so you'd get preferences too 20:00 popey, would have the largest outreach on the social mediums ... 20:00 I'm happy to do it 20:00 :-) 20:01 Cool. I like it 20:01 Grooveshark, grooveshark, grooveshark. 20:01 hah 20:01 meanwhile bg-playlists https://requests.ci-train.ubuntu.com/static/dashboard.html#?q=ubuntu/landing-048 ready for QA and getting there slowly 20:02 next week i'll try and run through our branch and continue working with jim to get the fixes in mh 20:02 I know we're going long here, but what are our priorities right now? We have so many spinning plates at the moment? 20:02 convergence + bg playlists + streaming 20:02 i would say bg playlists .. then convergence + streaming 20:02 I know streaming's probably the last one 20:03 We are also kinda blocked on convergence, actually 20:03 but tbh you can hop between them as we get so far with bg playlists then the mh guys need to patch things...so its been ok so far 20:03 The new AdaptivePageLayouts doens't work with tabs 20:03 and the silo containing the working convergence stuff for nexus 4 is busted 20:03 ugh...hmm but would we have tabs in the converged view? 20:03 i thought we were going to have head sections 20:04 oh but the point is that the adaptivepagelayout adapts to the mobile view :-P 20:04 vthompson, didn't timp comment on that? did he say it was WIP? 20:04 I don't think we've said we are going to move our tabs to be head sections? 20:04 i see no tabs here... https://docs.google.com/file/d/0B3XynHVKfrvMejVpQVhUd1J3ZWM/edit 20:04 ahayzen, he did. He also had some good ideas about moving away from tabs. But it'd take us a while to get there 20:05 ah, I forgot about that 20:05 :-) 20:05 that should be a poster over your bed :-) 20:05 I think it'll be awhile IMO before we move away from tabs... if we did we'd do what dekko does 20:06 yeah i guess 20:06 ok so is that it ? 20:06 i sense there is alot todo :-) 20:07 I think so. ahayzen when you start cranking out code next week, maybe look at mh3 support first 20:07 The silo installs now and things seem to work 20:07 okies i go back home on sunday, so monday :-) 20:07 awesome 20:07 popey, is that all? 20:08 also we've run into weathers time :-) 20:08 popey, for the converged view--or the first cut of it--when do we want something in the Store? That might change how we do convergence as a first cut 20:08 hm 20:08 i would say we would want it in trunk 20:08 ie, our MWC prototype vs something using AdaptivePageLayouts etc 20:08 we can't have like 3/4 branches going 20:08 we already have bg-playlists ... streaming... trunk 20:09 Do we have convergence designs? 20:09 https://docs.google.com/file/d/0B3XynHVKfrvMejVpQVhUd1J3ZWM/edit ? 20:09 but we don't have specific views IIRC 20:09 hah, just that one? 20:10 also we have a meta bug tracking bad views in landscape https://bugs.launchpad.net/music-app/+bug/1397582 20:10 There was a recent blog post I can't find, perhaps from t1mp? 20:10 about convergence layouts. 20:11 yup adaptivepagelayout ? 20:11 https://developer.ubuntu.com/en/blog/2015/08/10/adaptive-page-layouts/ 20:11 popey, yep, that's what ahayzen and I were talking about 20:11 what we were just discussing ;-) 20:11 right, thought so 20:11 sorry, friday brain melt 20:11 popey, so back to the question. When do we want a converged music app in the store? 20:11 So really, we need updated really crisp designs for convergence _and_ streaming 20:11 popey, true 20:11 I don't have a date 20:12 but before the end of the year, I think. 20:12 A first cut converged app probably won't exactly match the designs though 20:12 yeah but we can probably get something once these SDK things land 20:12 okay. 20:13 maybe we should wait and only play around with the convergence stuff until we have new designs with streaming added? 20:13 ...the framework is bumping for OTA6 right? 20:13 1.3? not sure. 20:13 I still want to play with AdaptivePageLayouts... let's just not land anything prematurely 20:13 well if they add mh bg-playlists...surely thats a framework bump 20:13 hm 20:13 as if we change to that our app will break on all old devices 20:14 it won't even launch 20:14 so really, convergence we have a date for (albeit fluid), streaming we do not 20:14 I don't think there will be a framework bump at all. 20:14 ugh 20:14 this is what we've said before we *need* a framework bump when ms2/mh change 20:14 ahayzen, yea, it might be ugly but we'll just need to be careful 20:15 but it won't even compile and run? 20:15 there are no more frameworks on my rc-proposed device than my retail krillin 20:16 like all these Playlist objects http://bazaar.launchpad.net/~music-app-dev/music-app/media-hub-bg-playlists-rework/view/head:/app/components/NewPlayer.qml#L65 i don't think exist currently ? 20:16 ahayzen, maybe we can have Jim put in some sort of value in the MediaPlayer component we could check? 20:16 they were added/exposed with the new bg playlists 20:16 so when the qml compiling thingy comes along it'll shart itself 20:16 ahayzen, maybe we'll just need some ugly checks in the app to ensure things still work 20:17 hmm i've got an idea 20:17 like put it in Loaders 20:17 with the source to a path 20:17 then it don't load but we'll need a flag to tell when 20:17 and even then other parts of the app depend on the new queue 20:17 i really don't want to be having duplicate code for both cases in there 20:18 i'll have a chat in the week with Jim for the best way forward for this 20:18 Same, but not sure we have a choice 20:18 :'( 20:18 Ok, so to wrap up bg playlists is the def primary focus, and we'll play with converged components as we have time. We'll wait on streaming until we have some designs... but we should discuss with design what's possible 20:19 ok is that all shall we move onto weather? 20:19 the OTA-6 image is due to be built on tuesday 20:19 yup agreed 20:19 with a view to release soon after 20:19 tell them to bump the framework ;-) 20:19 * ahayzen hdies 20:19 lol 20:19 * ahayzen hides 20:19 are either of you able to make it to a meeting on monday with design? 20:19 probably 20:20 i'll be able to confirm probably on monday though 20:20 I could try, but it's not very likely 20:20 or maybe late sunday 20:20 but like most likely i'll be about 20:20 well I can't schedule till monday morning 20:20 when everyone is back 20:20 Good point 20:21 So you two work out a time and if I can be there I'll be there 20:21 cool 20:21 (and rather work out a time with Design as well) 20:22 ok all done? 20:22 ok 20:22 #endmeeting Generated by MeetBot 0.1.5 (http://wiki.ubuntu.com/meetingology)